Elektrified X.org released (was: X configuration paradigm, and a proposal)

[Sean Middleditch]

On Tue, 2004-11-30 at 12:17 -0500, Alan Cox wrote:
> On Tue, Nov 30, 2004 at 01:34:47PM -0300, Avi Alkalay wrote:
> > 
> > >         3.      You might run out of disk space
> > >         4.      You need rollback
> > 
> > So the app handling the keys must be mature enough to roll it back.
> 
> In ten lines of shell script. Rollback belongs in the configuration libraries
> so you can do commit(list of key changes). That handles out of disk for
> free also.

Indeed.  Any configuration system like Elektra basically needs some real
database functionality.  This isn't a problem - it's 100% possible.
Elektra just needs to export the API, and leave the implementation
details of it to the backend.  A Berkeley DB backend for example could
easily implement transactions and such.  (Or do you need one of the
commercial BDB variants for those?)

Looking at the API, it appears that Elektra is already pretty much
"there".  Just grab a KeySet, set the keys, and save the whole set.  You
just need to guarantee that saving a set is atomic.  i.e., make sure
everyone backend does this, and clearly document this.

So far as implementation, this really is easy even with a (single) file-
based backend.  Robustness might take some work, but the basics are
easy.  You simply keep a list of all they keys that have been set, and
when the Commit command comes along, lock the file(s) in question and
modify them.  On Rollback, just "forget" all the key changes that
haven't been committed yet.  Basically the hard part for the simple file
backend is getting the commit to stay atomic on errors when you use
multiple files.  If you have multiple files being changed, I don't
believe it's actually possible to be 100% atomic - you can reduce the
chances of something breaking, but there will always be various race
conditions in regards to when errors occur that could leave you in a
half-committed state.


Getting intricate behaviour with shell scripts is also quite possible.
You would probably need some kind of service daemon.  So you'd write
something like:

#!/bin/sh

# this would print out code to set an  environment variable, so the code
# gets executed by eval, setting the variable
eval(kdb begin)

# set some keys - the command would check for the environment variable
# defined by the shell service daemon, and communicate with the daemon
kdb set "key1" "value"
kdb set "key2" "value"

# do some other stuff, including checking values of keys, which would
# also communicate with the daemon if the env-var is set
if [ `kdb get 'key2'` = 'value' ] ; then
  do-some-stuff
  set-some-other-keys
fi

# commit/rollback/whatever - again, checks env var, daemon, etc
kdb commit

#eof

The daemon would take some work to get working robustly (i.e., noticing
when its parent exists without shutting it down, and thus shutting
itself down cleanly after doing a rollback op, etc.) but its certainly
possible.

> 
> > About storage, 1 file per key or 1 file per folder uses almost the
> > same amount of disk space. Do a 'du -sk' in gconf storage folders to
> > see that.
> 
> In a db4 hash overhead seems to be percentage points. In flat file its
> about 3.5K per key for single key per file. It is implementation detail
> compared to the fundamental goal.

The author has this unfortunate tendency to use ReiserFS and other non-
mainstream file-systems and claim everyone else should too (Linux
Registry, the previous name for Elektra, was shot down repeatedly due to
his disregard for real-life systems) so he probably doesn't see any of
the over-head for small files.

A db4-baed system certainly has technical advantages in terms of
efficiency, but stop and think - you're basically now running the
WIndows Registry.  The Registry's *largest* problem is that it's a
binary format that easily gets corrupted - a lot like Berkeley DB (hell,
I wonder if that's what the Windows Registry's code is based off of
~_^ )

The best format is probably something like XML, or something very XML-
ish, because it can easily store a hierarchy in a single file, is "safe"
in terms of value escaping (many custom formats are not), and there are
tons of libraries to read/write it efficiently.  It isn't *easily*
edited by hand, but if it's "pretty-printed" it can be easy enough.

> 
> Overall I'm glad to see this work being done. I'm not convinced the format is
> right but the essential goals of unifying configuration spaces, improving
> tools and also just going out and doing it are all good things.

Definitely.  Elektra still has major short comings (no transactional
guarantees, no notification, no real access control, no temporary
keys... mostly things Elektra can never do since it refuses to use a
daemon), but it's at least a tiny step in teh right direction that might
open some peoples' eyes.

> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.