D-Conf (was: Post or during the Common VFS (D-VFS) ages ..)

[Avery Pennarun]

On Fri, Mar 04, 2005 at 10:18:31AM +0100, Philip Van Hoof wrote:
> On Fri, 2005-03-04 at 04:42 +0100, P. Kaluza wrote:
> > - Avery, what is the status of UniConf ? what is your current main focus ?
> > - What about the Elektra team ?

Funny you should ask.

UniConf has two major flaws that prevent it from becoming the "standard"
configuration system:

 - relatively big and C++, with too many dependencies.  You get a huge
   amount of power for all this - more than any other config system, I'm
   willing to bet - but most people don't want/need all that power.

 - relatively ABI-unstable because we're more interested in adding power
   for now than in stabilizing the ABI.  And C++ ABI stability is a PITA.

These problems are not going to go anywhere fast, so I'd like to officially
drop UniConf from this particular race - the race for being the "standard
Unix configuration system" API.

However, *I* want all that power, and I want it all throughout *my* Unix
system.  That means the plan for UniConf comes in two steps:

 - make sure a config system exists that *doesn't* have the above two flaws
   and has all the API flexibility I want, and help it to become popular.

 - make sure there's a UniConf backend for that system.

My current favourite for the standard is Elektra.  Avi's working hard on
this one, it has an active mailing list with people wanting to use it and
contributing patches, and he's taken several ideas I've sent him (about ABI
stability, API flexibility, and pluggable backends, not coincidentally) and
turned them into code.  The library is also plain C, well-written,
security-conscious, and tiny, which eliminates whole classes of objections.

Elektra is continually criticized for its one-key-per-file storage system,
but this is a total red herring.  It has pluggable backends.  The default
system is super-easy to implement and uses kernel-level security, so it
*will* be secure and easy to use, without a tonne of code.  And it has a
UniConf backend, in case you need more power.  (Yes, I know you didn't want
any arguments related to stackability.  But stackability is a huge benefit
of standardizing on one config system, so we might as well take advantage of
it!)

> As far as I know. At this moment is GConf the only system of these three
> that has a wide userbase. My opinion is that this fact can play an
> important role when the migrating-part starts.

Definitely true, except that it pretty much has to be rewritten from scratch
in order to become cross-desktop.  The KDE people are just plain not going
to buy into something that uses CORBA, I'm afraid.  Never mind that it
currently has more giant dependencies than UniConf, and I'm embarrassed
enough about UniConf :)

But as far as I'm concerned, GNOME compatibility with whatever config system
becomes "standard" is already a solved problem via pluggable GConf backends.
That means if GNOME people don't want to switch away from GConf... I don't
care.  And neither should you.  They'll get all the advantages of
standardization anyway through GConf backends.

KDE is in more trouble, because KConfig's API (unlike GConf) isn't
semantically powerful enough to do everything they want to do, like
network-transparency and notifications.

> We don't need a system that will magically convert files from /etc/ and
> all dotfiles in your $HOME into a unified database with triggers. Well
> perhaps the UNIX-world does need such a system but it's not within the
> scope of what the desktop-world needs. Perhaps later in time, both
> systems will work together or merge their features. But for me, at this
> moment, desktop-application configuration and system configuration are
> two different things.

That's fine.  Someone can do this work, or not.  Doesn't affect anyone much
unless they care about this feature.

> What we need is a registry-system for DESKTOP applications. It's only
> for the desktop applications. I don't think configuring apache with it
> is interesting. I don't believe system administrators would like it that
> way. And I'm certain the apache-team won't ever convert apache to use
> that system (nor any other UNIX system-service).

Well, the apache team has pluggable configuration systems as of apache 2.0,
so that's kind of not a problem either, assuming someone wants to write the
appropriate plugin someday.

> This desktop configuration system should have events and triggers for
> when values change. It shouldn't encourage binary data. It should
> encourage documenting keys. It should work network-transparant at
> protocol-level. This way a configuration daemon can be running on a
> dedicated host and clients can then work with it. Therefor it should
> have fallback mechanisms for in case the daemon can't be reached (to use
> a default scheme distributed with the applications).

Note that D-BUS is still intra-computer only (that is, it doesn't use the
network).  I don't see why nobody has extended it to network awareness yet,
since it looks like it would be easy, sensible, and reliable, but they
haven't.  That means even a rewritten GConf wouldn't get you network
transparency.

I would rephrase your requirements a bit:

 - it must have events/triggers/notifications of some sort, yes.

 - it should *allow* binary data, and *allow* documenting keys.
 
 - it should *allow* a network-transparent protocol to be implemented,
   but that should be invisible to the API.  The basic implementation
   should be tiny and not *require* this feature to be done.
   
 - it shouldn't *require* a configuration daemon, but could allow one
   if that makes sense.
   
 - it should *allow* a central configuration repository with
   default/current/override settings.

Elektra meets all of these requirements.  GConf-rewritten-to-use-DBUS, if it
existed, would as well, except that it would probably *require* a
configuration daemon because DBus just does.  Luckily, though, DBus is small
and simple, so this daemon wouldn't be overweight.

> Perhaps there might be a need to push new configuration to distributed
> configuration daemons. For example when your company has multiple
> configurations. Suddenly you, as the administrator, want to push a
> specific configuration key/value on all those different
> configuration-sets without altering their individual specific configs.

Most people don't need this.  If you're unusual (like me) and you do, you
could just install the UniConf backend.  Code already written.  Don't bother
writing it again.

> I don't know what undo/redo capabilities GConf has, but I've read it has
> planned such features. I don't know how atomic/transactional GConf is,
> but I've read it has planned such features.

GConf is atomic/transactional enough.

There is a neat project (whose name escapes me) for managing GConf history
in a more sensible way than just undo/redo.  It keeps track of your GConf
state at different times and lets you make snapshots, then recover those
snapshots.  ("Oh, darn, I broke something today sometime.  Let's go back to
yesterday's settings.")

> GConf can store it's configuration-data using different backends. XML is
> it's default and I'm not sure whether or not it is a real requirement to
> have multiple backends. I'd say its a "nice to have"-feature. As long as
> the data can be properly backed up and restored (XML can).

Bah, they all have pluggable backends nowadays anyway.  You're too late to
design one without that feature.

> Indeed. Most of the features a lot authors tried as arguments for trying
> to get their system accepted as "the standard" aren't worth it or aren't
> going to be actually used for desktop applications. Desktop applications
> don't need all that much. They certainly don't need to query files like
> apaches /etc/[apache|httpd]/httpd.conf.

Right.  This is why you should aim for a *tiny* system with maximum
*flexibility* in adding *optional* backends.  To me, that's either Elektra
(exists) or rewritten-GConf (doesn't exist).

You can see my obvious bias toward code that already exists instead of code
that doesn't.  Of course, the other side the argument is which one is more
*popular* right now, and GConf is clearly winning there.

Have fun,

Avery