Re: [Scrollkeeper-devel] system similar to ScrollKeeper

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

On Wed, 22 Nov 2000, Ali Abdin wrote:

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

Yes.  Nothing I said contradicts this.  I'm just saying that in addition
to publishing a "recommended" categorization system, we also accomodate
documents which fall out of this recommended categorization and
categorizations other than the recommended one.

So if a user wants to copy the standard contents list and add a section
called "DocsIWrote" or "Favorites" to it, they can do this.  Similarly,
they can (eventually) create OMF files under $HOME/.scrollkeeper/omf/
which can populate these sections they create in their contents list tree.

[SNIP]

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

Yes. This is the plan.  We have not worked out the details here, so if you
would like to suggest how this API would work, please do.

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

Yes.  We should go through and make sure this is fixed everywhere.  I see
that the example package does it correctly.

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

Most metadata searches belong in ScrollKeeper.  This is partly because
ScrollKeeper should be handling the metadata instead of the help browser,
partly to reduce the work which must be duplicated in each help browser, 
and partly because we will eventually have ScrollKeeper acting as a
"middle-man" between the help browser and metadata servers on the Net
which can handle these queries.

The particular example you give is more of filtering (as you called
it) then searching, so it isn't as obvious where this belongs.  I think it
belongs in ScrollKeeper as well.

Is this something we are likely to use any time soon?  I think at least
for Nautilus we will not need this for some time.  If anybody else wants
it, then we can move it up on the TODO list.

> 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 ;)

Sounds fine with me.  

It sounds like you have been thinking about the library ScrollKeeper
should export to help browsers.  Perhaps you could write up a proposal
describing what you think it should look like?

Dan