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

[Avi Alkalay]

On Tue, 30 Nov 2004 13:57:01 -0500, Sean Middleditch
<elanthis at awesomeplay.com> wrote:
> 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

Instead of doing a lot of 'kdb set', you can generate an XML file with
the keys you want changed, and do 'kdb import keys.xml'. It will be
more atomic, and will use the kdbSetKeys() call which wraps
transaction support.



> 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.

I don't have a tendency to use ReiserFS, but it showed to be more
performatic and less space consuming then any other FS. And I do see
the overhead for small files.
The point is: only discussing ideas is very different that writing
code. In this last case you'll find issues that destroy entire
architectures you built in your head.
A single DB file and a deamon was obviously the first reasonable thing
to think and to implement, so read bellow.



> 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
> ~_^ )

Yes, this is one problem with BDB. BDB was the first thing used, and
droped in version 0.0.9. See the changelog:
http://www.germane-software.com/repositories/elektra/trunk/ChangeLog

The major problems with BDB or a daemon (that was also the paradigm
for the old old old versions) are:
- It is very difficult to implement hierarchy in a consistent way inside a BDB
- Elektra is system-wide by definition. So with a global daemon,
security has to be handled in the user-space daemon. And security is a
little thing that you may require this: is the best (kernel space) and
you have it, or you simply don't have it.
- Besides, you can't authenticate against a system daemon.
Authentication means to have a user to *type* a password or *read* it
from a file. Think about how authentication works in HTTP sessions,
LDAP, DB servers, etc. I'm open to hear ideas on this point.
- A daemon is a single point of failure.

These were the reasons why daemon and a single file (binary or text)
is accepted only in non-critical, desktopish, single user environment
(read GConf, that really makes its job!). Not systemwide.


> 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.

Read/write in memory, not on the disk. On the disk you have to rewrite
the entire file, so bye bye transactions.


> > 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.

Notifications is there already. Check the code. Transactions needs
some stabilization, yes.
What do you mean with "no real access control"? This is completelly
delegated to the best guy that can do it: the Kernel.
And what do you mean about "temporary keys" ?



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

Thank you,
Avi