UniConfed Elektra released (was: Elektrified X.org released)
apenwarr at freedesktop.org
Fri Dec 3 03:00:17 EET 2004
On Wed, Dec 01, 2004 at 02:33:27PM -0300, Avi Alkalay wrote:
> 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.
Okay, so I kept my word: I spent a couple of hours today writing a UniConf
frontend for elektra (AKA an elektra backend for UniConf). This allows any
elektra-using program to transparently use UniConf instead.
See the "unity" project, subdir "elektra", on open.nit.ca anonymous cvs.
The primary discussion list for this project is wvstreams-dev at lists.nit.ca.
(UniConf is a part of the wvstreams library.)
The combined solution has these interesting characteristics:
- you choose the storage type and transport. UniConf can use one or more
ini-style files directly (no daemon), or talk to a daemon via unix
sockets, tcp, tcp-ssl, or DBUS. It can also store its data in kconfig or
gconf. Someday someone will write a mysql/postgres/bdb/whatever backend
too (but there's already a bdb backend for gconf, and UniConf can use it,
so this isn't strictly needed).
- UniConf is carefully designed to support good network bandwidth/latency
usage in clusters and slow/unreliable networks.
- Apparently x.org is already supported, since Avi has patched it for
elektra. (Technically I didn't try this... just the kdb command-line
- UniConf supports efficient notifications, assuming you use a backend that
supports it. (Disclaimer: I didn't actually spend the half an hour to
make elektra use UniConf notifications instead of polling. It was neat
that the polling implementation worked in my backend without me doing
- Elektra provides a very small library that you can use at boot time
rather than requiring the rather big UniConf library for basic
functionality. Then, after booting, swap it out for something more
flexible and network-aware.
- Elektra has a native C API, for you anti-C++ weenies.
- UniConf has a native C++ API, for you anti-C weenies.
- Both systems have additional language bindings, resulting in a fairly
good amount of coverage between them.
I believe the remaining imaginable reasons not to use elektra for x.org's
configuration now come down to:
- People who don't like Elektra's tree format.
- Elektra's tiny library is still too big.
- Incomplete support for transactions.
- Elektra's API is somehow worse than the grotesque x.org monstrosity.
- Changing the x.org config format one more time would be inconvenient to
users. (Note: you could actually write a UniConf backend for the x.org
standard config file format, and access that from the Elektra API inside
the X server. But that's a bit too many layers of fluff for my liking.)
- Elektra's API can't do useful notifications except via polling (or
"simulated polling" - you at least have to keep calling its poll function
to check for changes, rather than it calling you).
- It is surprisingly easy to write new backends for elektra, although installing
them involves some .so-twiddling. It's not as nice as UniConf's
- Elektra's notification support needs work. It should have
registration/unregistration and callbacks, not "call this function
sometimes to see if anything has changed". Trust me, I've been through
this enough times already.
- The Key data structure should have keyNew and keyFree functions (allocate
and deallocate keys), not keyInit and keyClose. This would allow you to
make the data types completely transparent, making your library more
ABI-stable. You'll know you've done it right when there are no more
data structure definitions in kdb.h.
Hey, Avi, can you convert apache next? Or how about samba? :)
More information about the xdg