Re: [Scrollkeeper-devel] system similar to ScrollKeeper

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

* Dan Mueth (d-...@uc...) wrote at 01:48 on 23/11/00:
> 
> 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.

Well - you actually said "We need to decie what happens to docs which fall out
of the categorgization" - I am saying, you do NOTHING when they are not in the
categorization tree. You just use the provided category "as-is"
 
> 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.

You don't need a standard contents list as far as I know?
Why would you need it if we "don't care" about the category?

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

Actually - the way it usually works is you provide the API for the
functionality you /think/ we need, we comment on it, you revise, then we start
using it, then we start complaining and you revise again ;)

Basically, the return time for most operations would be a xmlDocPtr that the
application/viewer would have to parse ;) Thats the only input I have at this
time (its 2AM and I'm tired)

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

Well, I'm not sure Nautilus will be moving to ScrollKeeper quite so soon (i.e.
if you're gonna switch to a library, then why should we use the current set-up
that Sun submitted)...I'm not sure...we'll have to see.

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

Actually, I'm way too busy to do that (to compound the matter, I have the
final round of midterms, then finals, then travelling to Kuwait) - I also have
a bunch of stuff that needs higher priority (backlog of patches for Nautilus
help stuff)...

if you can come up with something, great. If not, then I guess i'll try to do
it in my freetime...

Regards,
Ali