Re: [Scrollkeeper-devel] What about the distributions?

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

On Thu, 26 Oct 2000, Eric Bischoff wrote:

> Ali Abdin wrote:
> > 
> > 
> > Perhaps what we need are two directories or something. So you would have:
> > prefix/var/lib/scrollkeeper/processed
> > prefix/var/lib/scrollkeeper/unprocessed
> 
> This is great!!!! :-)
> 
> a) during "make install"
> "scrollkeeper --install" will stores the partial information in either
> /var/lib/scrollkeeper/unprocessed (end-user doing "make install")
> or in
> /tmp/var/lib/scrollkeeper/unprocessed (packager building the package)
> 
> b) during RPM installation
> then the unprocessed file is simply copied into
> /var/lib/scrollkeeper/unprocessed
> 
> c) when the help browser starts
> it is requested to launch "scrollkeeper --update". This one sees that
> they are unprocessed files,
> merges them into the real database, and removes them from the
> /unprocessed directory.

No this really really sucks actually. App authors shouldn't be forced to 
execute scrollkeeper --update everytime somebody wishes to browse a help 
file.

The decent options to me (for this approach) would be to:
1) Use a cron script
2) Make scrollkeeper a daemon
 
> In fact the "unprocessed" directory should be two directories:
> 
> 	/var/lib/scrollkeeper/toinstall
> 	/var/lib/scrollkeeper/touninstall
> 
> because we're having the same problem during uninstallation.
> 
> > An "initial" scrollkeeper-install would put the file in the unprocessed
> > section, scrollkeeper could then at some designated time, check all files in
> > the unprocessed section, if they are found on the local drive they are moved
> > to processed, otherwise they are removed from unprocessed.
> > 
> > But this presents another issue. What about "online docs"? the above
> > implementation would force people to have docs on the "local" path!!! Instead
> > of deleting the file, perhaps we should move it into a "not-installed"
> > directory. That way if the help file is located at
> > "http://www.doc.com/file.sgml" We could access it from the not-installed
> > section.
> > 
> > The problem would arise with "syncing" the two directories (what if you have a
> > "not-installed" doc and then later install it locally)
> > 
> > So perhaps we shouldn't have multiple databases (or directories, or whatever
> > you want to call it). Perhaps we should always install files...
> > 
> > If a doc is not found/installed locally then ScrollKeeper should handle it.
> > This sounds a lot like what Eric was saying doesn't it? ;) But he makes it
> > sound that applications (help browsers) should handle it. Instead, I think
> > that ScrollKeeper should natively handle it.
> > 
> > If I ask the ScrollKeeper database for "all installed docs" it would return
> > that - I /could/ ask for all "not-installed" docs (which would return these
> > docs + the HTTP ones + FTP ones + etc...)
> > 
> > Generally, when a help browser displays its "Index" (for Nautilus that is the
> > Help Sidebar) it would only display the "installed" docs...
> > 
> > What do you think of this proposal?
> 
> Great. I'm not sure about the online docs, but for the local docs it's
> really a good idea.
> 
> -- 
> Éric Bischoff  -  Documentation and Localization
> Caldera (Deutschland) GmbH - Linux for eBusiness
> Tel: +49 9131 7192 300 -  Fax: +49 9131 7192 399
> http://www.caldera.de/
>