Re: [Scrollkeeper-devel] ScrollKeeper-0.1 Proposal #3

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

On Tue, 14 Nov 2000, Laszlo Kovacs wrote:

> > > This would pose a significant problem.  The original design installed each
> > > document with something like:
> > >
> > >     scrollkeeper-install <omffile> <doc>
> > 
> > I think that's probably a bad idea.  Each OS is going to have its own idea
> > of what program to use to physically install the document, and set the
> > ownership and permissions properly.  I don't see much point in reinventing
> > install(1) or cp(1).
> 
> This is a misunderstanding. It is an addition to install and cp, not a
> reinvention. It installs the doc into the Scrollkeeper database after it
> was installed with install or cp to the right location.
> 
> > I think it's probably better to provide a scrollkeeper configuration
> > file (in XML would be nice :-) ) that describes a list of paths down
> > which scrollkeeper (sk from now on) should recurse to look for new
> > documentation.
> There will be some solution in the future to extend the one directory
> where metadata files are now to a set of directories. This is for
> metadata only, Scrollkeeper intends to support cataloging of docs based
> anywhere locally and on the web, this is why we thought the metadata
> should contain the url.

Perhaps we should use a URI instead of a URL (so a local file would be 
'file:///usr/doc/foo.sgml' or 
'http://scrollkeeper.sourceforge.net/manual.sgml' - but that would suck, 
because you'd have to handle the URI parsing (which will just duplicate 
code that is in gnome-vfs (and prolly some other KDE library out there))
  
> > Most package systems should provide a mechanism to call scrollkeeper-install
> > after a document has been added to the system, ideally with the path in
> > which the document was installed.  For those that don't, the system can
> > run something periodically that re-indexes the list of installed
> > documentation, in the same way that the apropos database is built at the
> > moment.
> The problem with this is that packagers will have to create large
> postinstall scripts to get it working right and some of the people on
> this list think they will not do it if the changes are not as simple as
> possible. If we disregard the packagers possible reaction then most/all
> of the Scrollkeeper related process should be launched from postinstall
> scripts. But as I said some people strongly opposed that.
> 
> > Depends how well written the package is.  Most of the FreeBSD ports install
> > with $PREFIX set to something other than /usr/local with no problems.
> > 
> > Also, keep in mind that some of these packages are going to consist of
> > nothing but documentation.
> > 
> > For example, *right now*, a FreeBSD user can do something like
> > 
> >     pkg_add -r -p /opt/share/doc \
> >       ftp://ftp.freebsd.org/pub/FreeBSD/doc/packages/handbook.en_US.ISO_8859-1.html.tgz
> > 
> > This will download the HTML version of the English FreeBSD handbook, and
> > install it under /opt/share/doc (instead of the more usual /usr/share/doc).
> > 
> > Now, pkg_add in FreeBSD has hooks to allow post-install scripts to be
> > run, that could call an sk command to update the index.  But the sysadmin
> > should also be free to create /usr/local/etc/scrollkeeper.cf, and make sure
> > that "/opt/share/doc/" is listed as a directory to be indexed.
> This suggestion does work only if the doc is locally installed, what if
> I point to a page on the web, where the document is?