configuration system notes

Havoc Pennington hp at
Thu Apr 7 17:18:23 EEST 2005


Previously I have posted:
which are some changes to make to gconf, with three of those changes
prioritized as more important vs. the others.

I just posted this also:
which is an example rough spec for a system that addresses the points in

I think these documents are a reasonable approximation of what GNOME
would find compelling and what Fedora would find compelling for
systemwide configuration. So someone needs to listen to this, and listen
to the KDE team, and apply the resulting knowledge to actually writing

It's pretty obvious from most of this discussion that many people have
not understood my "how to improve gconf" notes, or understood the
advantages and disadvantages of gconf itself. A new system without that
understanding is _not_ going to be better, and that means GNOME won't
use it.

I don't know if it's possible to get Mozilla and on board or not;
there are several tricky aspects, including cross-platform and that at
least has such a huge amount of data in the system (I can't
imagine all of that data is what we'd consider "preferences" on the
GNOME/KDE level, but I don't know). I think it would be OK to skip these
apps at first if it looks intractable to cover their use cases. But it 
would be nice to cover them if possible.

Existing systems are not right:

 - Uniconf solves a different problem (gluing together other systems)
   while punting on important aspects of what we should be doing here.
   "Make it configurable" is not a good answer to most programming 
   questions (not even the question "how should the config system work")

 - 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 

 - ACAP is a standard nobody uses, and is pretty different from 
   the ideal design, so I see no reason it's interesting.


More information about the xdg mailing list