Re: [Scrollkeeper-devel] system similar to ScrollKeeper

[Dan M. <d-...@uc...>]

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.

> > 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.

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.

Dan