UniConfed Elektra released (was: Elektrified X.org released)

[Avery Pennarun]

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
   client.)
   
 - 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
   any work.)
   
 - 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).

Other comments:

 - 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
   /etc/uniconf.conf.

 - 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? :)

Have fun,

Avery