|
From: Eric B. <eb...@cy...> - 2000-11-13 15:35:48
|
Le Samedi 28 Octobre 2000 00:34, Ali Abdin a écrit : > > We can build a single one out of the "not-installed-yet" partial > > databases. > > When do we do the "building" though? It is NOT acceptable to do the merging > whenever we do an API function or whenever the "browser starts". > > We "could" make scrollkeeper a daemon (like oafd and gconfd). We could then > have a 'scrollkeeper_init()' API function that would check if the daemon is > running (if its not, it would execute it). You could also have a > is_scrollkeeper_daemon_running or something. I think this is very similiar > to the way oafd is done. > > The daemon would "merge" the not-installed-yet to the "single one" when > started and every <X> amount of time > > This is up to Laszlo though. If one examines how the existing help environments do, he notices that: - man pages have a cron daemon which I suppose does some reindexing - info pages require you to call an install-info utility from the postinstall and postuninstall scripts (and this sucks) No one calls the reindexing function from the browser. This tends to confirm what you say. > > You can't "make" people do what you want. If they don't want it, they > > won't do it. > > Exactly - people have to /want/ to use Scrollkeeper What do you do for that? Light candles and pray? Let's be serious. No one will want to adapt thousand of spec files for a new help indexing system. > > > If you want your docs > > > to utilize scrollkeeper, then you will have to support it. > > > > "you" in the above sentence is two different persons. > > If you speaking about Debian, the package author is "usually" different > than the packager. > > Unfortunately (or fortunately?) it is usually the opposite with RPMS. The > author also handles the .spec files ????? This is simply completly wrong. -- É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/ |