Killing scrollkeeper (again)

[Don Scorgie <DonScorgie Blueyonder co uk>]

Hi,

After I posted my proposal a couple of days ago, I received various bits
of feedback from various people.  Thanks.

I also had a long discussion with shaunm on IRC about it.  He pointed me
towards an old discussion between him and Cornelius Schumacher (KDE
KHelpCenter developer) about a joint help system.

Having digested the discussion as well as the various bits of feedback,
the main points seem to be:
* No registering system for metadata
  - Registering makes baby jeebus cry, as well as packagers, doc
writers, translators, developers and anyone else that stumbles across
them
* Ditch omf files
  - No-one likes them.  They're a pain to deal with
  - KDE don't like XML

Since previous discussions have always seemed to dry out without a
consensus appearing, and since I got bored, I decided to stop the
discussion from dying out this time.

And what better way of keeping it going than to present some code?
Attached is a stupid first attempt at making this scrollkeeper killer
(alas still with the moniker "Spoon").  NOTE:  It's not actually
attached.  It can be gotten from:
http://www.donscorgie.pwp.blueyonder.co.uk/spoon-0.1.tar.gz

It consists of the libspoon library, along with 2 utils.  The first util
is the spoon-sk-migrate{-all} script, which can be used to convert omf
files into "Spoon Scrolls", which are keyfiles, much like .desktop
files.  The second is a spoon-example program to show what the library
can do.

<Disclaimer>
The package is very fragile, and will probably fall over if you look at
it funnily.  It won't work when installed, as all the paths are
hard-coded and require the existence of the data dir in the current
directory.  There is only very minimal error checking and argument
parsing.

The scroll files, parsed with libspoon, will only handle 3 fields:
name, description and docpath (Guessing people can figure out what these
are).  Other fields are ignored.  There is also a hard-coded limit of
1012 characters for each field (which shouldn't cause any trouble).

It also only finds scrolls of the form
data/sk-import/<package-name>/<package-name>-<lang>.spoon
and won't pick up (e.g.) the gnome-games files (which are:
gnome-games/gatixx-C.spoon for example)

</Disclaimer>

When run, the convert script will read each omf in /usr/share/omf and
produce an equivalent .spoon scroll in the same directory structure
within the data dir.

libspoon then reads and parses these files when its inited (sussing the
correct locale, hopefully, from the LANG environment variable).  It also
provides a for-each function to iterate through all the scrolls in it's
list.  In the spoon-example program this is used to iterate through and
print the title of each document.

Running the convert script takes (on my machine) ~ 1 m 30 secs to
complete ~ 500 omfs.  Running the spoon-example program takes between ~
0.1s (warm cache) to ~ 0.9 s (cold cache), including printing all the
titles out.

It's worth noting[0] that if this replaced scrollkeeper, there would be
no slow-down from Yelp [1] as yelp must iterate through each omf file
individually to extract the necessary information.  In fact, there would
be a speed-up, as scrollkeeper doesn't need to be called, the index file
doesn't need parsed and spoon initialisation can be done early in the
program, allowing other things to work while it collects its
information (provided spoon creates a new thread and returns quickly).

Anyway, enough babbling from me.  For more info, see the README file.  A
couple of questions: What do people think?  Worth continuing?  Anything
about the design that seems strange or odd or you don't like?
Don

[0] Okay, its not really worth noting.  I just thought I should add it
anyway.
[1] Well, at least compared to pre-cache-enabled TOC generation