Re: [Scrollkeeper-devel] Handling relocatable packages

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

* Nik Clayton (ni...@no...) wrote at 03:49 on 26/11/00:
> 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.
> 
> [...]

So we should support FreeBSD and not Linux? (this argument works both ways). I
am just saying we should support both relocatable and non-relocatable packages
(you asked for an example of non-reloctabale package, and I gave you one
(GNOME on 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]
 
> > 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).

Yeah...although I'd still like a HTML and/or plain text version (just to avoid
the visual clutter of the tags). Wait, actually Mozilla now can decently view
XML files so that may not be a problem ;) but whatever.

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

Well - by default, I recommend non-interative prompts..
 
> > > > >   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.

ScrollKeeper /has/ to pick an XML library to rely on for parsing stuff. I was
just suggesting "publicizing" this in the API...Anyway, you /could/ have
libxml-specific stuff trapped in #ifdef's and just provide "other" people with
the FILE descriptor to do their own parsing.

Or, we can make libsk.so libxml-specific totally and then force people who
wish to use something else to use the scripts and/or command-line tools.

Note: to compile (and run) scrollkeeper you will need to have libxml
installed.