Caching jobs

[Tristan Wibberley]

On Tue, 2007-10-23 at 23:11 +0100, Scott James Remnant wrote:
> On Tue, 2007-10-23 at 22:11 +0200, Jan Claeys wrote:
> > > The parser is a string one; so it could be faster by being binary ...
> > > but it wouldn't actually buy you anything; you'd have to re-parse the
> > > text files on boot to make sure they hadn't been changed while the
> > > computer was off.
> > 
> > Storing the last file modification time inside the "binary blob" might
> > be good enough?
> > 
> It's incredibly expensive to walk a tree of files and stat() them ...
> shockingly.

A solution to this is to only update the binary blob on explicit
request. Treat the human readable files as source and let the admin
compile them. This allows the parser to not run at boot time reducing
the chance of latent corruption and allows me to make modifications,
think about it for a while, then commit them - or go off and do my
shopping before the shops shut worrying about neither a power cut nor
the fact that I'm not finished.

As long as post-install scripts can update just their own part of the
blob the explicit compile step would be nice for me as a user of my
computer's init system.

A scheduled job to log that I've got uncommitted changes would also be
nice, along with a commandline version of the scheduled job.

-- 
Tristan Wibberley

Any opinion expressed is mine (or else I'm playing devils advocate for
the sake of a good argument). My employer had nothing to do with this
communication.