configuration system notes
hp at redhat.com
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
I don't know if it's possible to get Mozilla and OO.org on board or not;
there are several tricky aspects, including cross-platform and that at
least oo.org 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