Re: [Scrollkeeper-devel] Handling relocatable packages

[Nik C. <ni...@no...>]

On Thu, Nov 23, 2000 at 08:05:16PM -0200, Ali Abdin wrote:
> GNOME is non-relocatable...Nautilus is non-relocatable (I maybe incorrect, 
> somebody told me they were non-relocatable)

Gnome might be non-relocatable on a Linux system.  That's not the case
on a FreeBSD system.  All the world is not Linux.

[...]

> Now, I know there are probably hacks that can be done to get around this. I
> know that this may not be "theoretically" correct, etc. etc. etc. But the fact
> is there /ARE/ non-relocatable packages out there, and scrollkeeper should
> support both types of packages.

SK should not need to do anything different, once the data has been
installed.  We may need to provide tools that make it easy to rewrite an
existing OMF file if a document is being installed elsewhere (see my
description of sk-generate-omf in another message).

<snip>

> So, multiple databases does make sense in my opinion (think of it this way,
> just because YOU don't need it, or can't find a reason to use it, it doesn't
> mean that it is not useful for others)..

Exactly.  Tools, not policy.

> FAQ/Manual/HOWTO are not category types in your opinion...What I mean by
> categories is more like "subject" - i.e. "Audio/MP3 Players' or
> 'Office/Spreadsheet' or 'X11/Internet/FTP Clients' etc.

Maybe, maybe not.  SK shouldn't care.  Categories should be opaque types
to it.  SK should place no special meaning on any category.

> I am saying just a HTML file, or plain text file just LISTING the categories -
> nothing fancy...Scrollkeeper would have no knowledge of this file and will not
> interact with it in anyway.

XML, probably.  

SK would need to know about the file, so that it can do sanity checks,
and say things like

     The document you are installed lists a category that does not exist
     in the master category list.  Do you want to continue?

(or something like that).

> The scrips should NEVER EVER become "interactive". Just use whatever is in the
> category (in the OMF file).

People make typos.  SK should probably have a 'loose' and 'strict'
processing option.  It should allow people to shoot themselves in the
foot if they want to.

> > > >   application will have the responsibility for handling user queries of the
> > > >   SK TOC and Index files ]
> > > 
> > > sk should export searching functionality. 
> > 
> > How?  libsk.so?  By having a program that accepts search parameters and
> > returns XML with the results?  Some other mechanism?
> 
> I prefer a library that returns the xmlDocPtr of the file...

xmlDocPtr is specifc to libxml, isn't it?  What if I (as an application
programmer) want to use another XML library?  Since (part of) the point
behind XML is to reduce reliance on one specific parsing library, it
would be more open-ended if libsk could be used to find a document,
which can then be referred to by URL.  It's then up to the calling
application to open that URL and process it.

> > For example, on a BSD system, the contents of /usr/share/man change once
> > in a blue moon, as third party manual pages generally live under
> > /usr/local/share/man.  So the admin might want to create a Contents List
> > for /usr/share/man once, and keep it separate, because the SA knows its
> > never going to change, so it doesn't need to be included in any
> > processes SK undertakes to ensure that the Contents List is sync with
> > the filesystem.
> 
> I think this "optimization" is unncessary at this time. We have no data _AT
> ALL_ on the efficiency in scrollkeeper. We don't know if it will be slow or
> fast, so splitting up databases for this reason is unacceptable in my opinion.

I wasn't introducing it is an example of an optmisation, but as an
example of where an SA might want to have separate databases.

N
-- 
Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
Telephone line, $24.95 a month.  Software, free.  USENET transmission,
hundreds if not thousands of dollars.  Thinking before posting, priceless.
Somethings in life you can't buy.  For everything else, there's MasterCard.
  -- Graham Reed, in the Scary Devil Monastery