configuration system notes

[Avi Alkalay]

Havoc Pennington wrote:
> - Elektra has its priorities wrong. The obsession with avoiding a 
>   daemon and supporting early boot breaks more important goals.
>   If you need a no-daemon mode, make it a special case, not the normal 
>   case.

Elektra's priority is to solve whole system configuration zoo, not
only desktop's. Think about Apache's being integrated to Samba's
configurations, to be integrated to a generic desktop configs, to be
integrated to cron's configs, PAM, iptables, modprobe, Kudzu, HW,
BIND, ntpd, user's, network info, and everything else you can imagine.
K and GConf are good enough for their desktop world. To talk about
integration only between them is to reduce the problem to something
smaller that it really is. The configuration problem is huge and is
far beyond the desktop context. And I don't see it being addressed in
the discussion. Well, I almost forgot this is an FD(esktop)O list.

While making strategic decisions on how a config system should be, I
ask you to not forget the entire non-desktop software ecosystem out
there. Notifications, schemas, XML, multibackends, beautiful flexible
architectures, may be needed for desktop frameworks, but is pure
polysaturated fat for these essential subsystems. And you can't have a
desktop without those system elements. In the design process of
Elektra, I had to painfully avoid C++, client-server, XML, BerkeleyDB,
and many other cool stuff you can find in freshmeat.net.



> On Thu, 2005-04-07 at 12:03 -0400, Avery Pennarun wrote:
> > 
> > I think elektra, now that it has pluggable backends, is actually the current
> > best choice for "the" configuration system.  Perhaps if someone implemented
> > Havoc's "new gconf" spec, it would be nice... except that they haven't.
>
> But that's irrelevant because we already have GConf and KConfig, which
> are currently better than Elektra. We aren't going to downgrade what we
> have just to get a common system. The common system has to be an
> upgrade.

Elektra wants to address other problems. Not only the desktop, as I
mentioned above.

/sbin/init, for instance, won't deal with a config system that is
bigger, more complex, more resource demanding, than itself. Same for
cron, bind, etc, so they need some "almost as simple as text file, but
standarized" config system (in terms of security, simplicity, API and
availability) to deal with.

On the other hand, a complex OOo, Mozilla, KDE, Gnome, etc app can use
same underlying "standard" but with additional stacks of functionality
and APIs. And these last must keep being GConf and KConfigXT, because
they are really much much better. For a desktop system.

Avi