Re: [Scrollkeeper-devel] system similar to ScrollKeeper

[Ali A. <ali...@au...>]

* Dan Mueth (d-...@uc...) wrote at 22:57 on 22/11/00:
> 
> On Wed, 22 Nov 2000, Ali Abdin wrote:
> 
> > On Tue, 21 Nov 2000, Bob Stayton wrote:
> 
> > > 1.  A predetermined complete categorization of content is
> > > not useful or even possible.  Rather, an open framework
> > > of general categories can be established so providers
> > > have a place to hang their stuff.  But providers need
> > > the ability to add subcategories.
> > 
> > As far as I know - anyone can put their document in any category they 
> > like. But there should be a set of "recommended" categories for people to 
> > use.
> > 
> > This happens in RPM, people can put their category as anything in their 
> > Spec file, but usually they pick one of the "standard" ones.
> > 
> > Scrollkeeper will not "enforce" a strict set of categories, but I think a 
> > recommended list of categories should be published
> 
> I agree with this point of view.  Scrollkeeper itself is just a software
> package, not a specification.  The OMF is the spec for the metadata.  We
> will develop another spec for a standard category system for the contents
> list.  However, people should be able to use scrollkeeper with their own
> contents list.  (eg. in a classroom or computer lab for newbies)  I'd like
> to just point scrollkeeper to whichever categorization file it should use.
> 
> We need to decide what happens to docs which fall out of the
> categorization.  We have 3 options:
> 1) they are omitted
> 2) they are put in a generic "other" category(ies)
> 3) they are put in regardless of the categories file
> 
> We may want a configuration parameter to determine which of these 3 are
> done, since depending on your situation you may want any of these.

I disagree. ScrollKeeper should not "point" to or know about any categories.
It just uses whatever is specificed in the OMF file. So if the category is
'Audio/MP3 Player' it gets stays that, and if the category is 'ABC/XYZ' it stays
that 'way'.

What ScrollKeeper should do is provide a "list" (on the webpage, in the docs
section, etc.) of "recommended" categories to use.
 
> > > 7.  Clean removal of content is very important, and harder
> > > than you think.  The removal scripts need to clean up
> > > databases, views, and search indexes.  We didn't pay enough
> > > attention to this item, and most of our bug reports came
> > > after some content was incompletely removed.
> > 
> > Scrollkeeper would only be responsible for cleaning up its own databases 
> > and various files.
> 
> The current design is very clean in this regard.  All of the sk databases
> are under $localstatedir, but the OMF files are elsewhere (I think
> $prefix/share/omf).  So to kill the database you just erase everything
> under $localstatedir/scrollkeeper.  What is really nice is that to
> "rebuild" the database from scratch, you just completely blow away
> $localstatedir/lib/scrollkeeper and then run scrollkeeper-update which
> just looks in $prefix/share/omf to find all the OMF files, uses these to
> find all the docs, and then completely generates a fresh database
> (typically in $localstatedir/lib/scrollkeeper/) :)
> 
> This is one of the reasons we want to seperate the post-installation
> scripts into two stages: One which makes sure the OMF files have the right
> IDENTIFIER, and a second which actually reads the OMF file and doc and
> enters the information into the database.  This is also why we don't want
> the latter step to take any metadata as an input.  All the metadata must
> be stored in the first step so it is included in the OMF files which will
> be the primary source for this information, not the database itself.  
> This way if we upgrade versions of sk and the database format is changed
> somewhat, or when the database is corrupted, it is trivial to generate a
> fresh and complete database.  (It also means we don't have to write
> complicated scripts which try to migrate databases from one format to
> another as sk versions increment.)
> 
> > > I do think the ScrollKeeper project should develop one
> > > or more basic presentation applications, to the degree that it
> > > can.  This will make it useful "out of the box" and
> > > encourage content providers to add OMF data to their packages.
> > > It will also test the data and the API, and lead to 
> > > incremental refinement of both.
> > 
> > I disagree. This is not ScrollKeeper's responsibility. Hopefully, the KDE 
> > or GNOME team can provide an "example" program to show off ScrollKeeper.
> > 
> > In fact, I believe Sun is working on a 'Help SideBar' for Nautilus on 
> > this (umm, they just sent me a 500kb patch for the Help SideBar (which I 
> > will examine when I get home)).
> 
> ScrollKeeper's scope is not generally to provide applications like this,
> but I also originally thought that a very basic application or two
> illustrating how one uses the ScrollKeeper API and what ScrollKeeper can
> do would be useful.  It looks like the GNOME/Nautilus folks will (or
> already have) already have a help browser using scrollkeeper, so people
> will soon be able to look at that to see how it works.

I got a patch today from a Sun dude (Mark <something>, sorry I forgot the name)
that implements ScrollKeeper for the help sidebar (while still retaining the
old functionality)...

I'll probably integrate it sometime soon.

> It would still be nice to have these example programs, or even have a
> complete help browser which does not depend on all the GNOME and KDE
> libraries.  I don't personally place this high on my priorities list
> though.  If anybody else wants to write a desktop independent browser
> which uses ScrollKeeper then this would certainly be a Good Thing.

I have a gripe with Scrollkeeper right now...It appears that the only way to
interface with it is to use applications/scripts. 

I thought we were going to have a library that implements this sort of
functionality (to get the contents list, etc.) - I really don't like the idea
of using pipe's for the help browser (a library would also be more
efficient)...

Another mini-gripe...In scrollkeeper/cl/README it says 'foo.xml is the
document metadata file' - I thought we had agreed to use 'foo.omf' instead to
help identify the file easier?

Another question...Where will be the "burden" be of searching the index? For
example, say I want to "filter" the help files on the category 'Internet/Browsers'...Is
this the responsibility of the help browser, or is it in Scrollkeeper's
domain?

The ways to implement the above are:

1) We have an app/script that lists the entire contents, which you have to
pipe and then search on, then present
2) We have an app/script that does the filtering for you, which you have to
pipe and just present
3) We pass the xmlDocPtr of the entire XML database, which you have to search
on, and then present
4) We pass the xmlDocPtr of the "filtered" XML database

I think its pretty obvious that I prefer #4 ;)

Regards,
Ali