Re: The great "kill-scrollkeeper-with-a-blunt-spoon" Proposal

[Don Scorgie <DonScorgie Blueyonder co uk>]

Hi,

On Wed, 2006-07-26 at 19:19 -0400, Peter Williams wrote:
> On Wed, 2006-07-26 at 22:49 +0100, Don Scorgie wrote:
> > 3.2. spoon-register
> > -------------------
> 
> I'm not claiming to be an absolute authority here, but I think it'd be
> nice to avoid a -register program. Mono does this with DLL's in the
> Global Assembly Cache by defining exactly where they land in the
> filesystem. Then a package can just plop down the appropriate files and
> not worry about having to invoke install/uninstall hooks. In this case,
> you could say something like "put your OMF file in the following
> directory:
> 
> 	/usr/share/spoon-1.0/omf/<lang>/<seriesid>.omf"
> 
> or whatever. If there are any index files that need to be updated, you
> can rebuild them as-needed (I think you can just check the modtime of
> the containing directory?).
> 
> Anyway, in general, I'd say it's better to have a "just put a file in
> directory X and you're good" model rather than an "invoke this black box
> tool" model. At least it makes packaging a lot more straightforward.

Right.  I'll try and organise my thoughts on why I did this.  I'll
prefix it by saying:
The main aim of the package is to imitate scrollkeeper as much as
possible (at least to the outside world / packagers / translators /
doc-writers).  Internally, we can do whatever we want.

Okay, so onward.  Currently, when registering, scrollkeeper copies the
omf into <prefix>/share/omf/<package-name> and adds it to its index.

Basically, what your suggesting is that instead, when the library is
started, it scans all the directories and sees if any have mod-time and
adds any new / changed omfs to its index.

The first thing that sprang to my mind is the speed element: If we have
to scan ~ 150 directories on startup (which is a typical install),
adding any new files on the way, this is going to munch some amount of
time.

Then, another thought hit me: The library is intended to be used as
anyone-but-root.  Writing the index file after we've scanned everything
will require root access (or at the very minimum, owner-access).  We
don't want to allow random people to write entries into the index [1].
The index is intended to be global, accessible by anyone that can run
$HELP_BROWSER.

There is another possibility: run directly from the omf files.
Construct the index in-memory at run time from the omf files directly
and don't save them.  This may be the way to go, I don't know.  It would
slow down the process slightly: every time, we'd have to open the
corresponding omf file in each directory (scanning 150 directories),
read in the values, parse them into our structs.  If the file doesn't
exist, fall back to <file>-C.omf and parse that.  It would probably add
a bit more to the library than using an index and parsing 2 XML files.

I don't know.  Anyone with any feelings on the alternative routes,
please guide me ;)  My gut feeling is that using the -register prog
would make the library faster but the "scan-omfs" method might be a
better idea for packagers / maintainers of random modules.  Anyone?

Don
[1] Although, now that I think about it a little, it would be a nice
feature to combine indexes from the system-wide stuff and docs stored in
the users home directory...  hmm.