D-Conf (my first conclusions)
Philip Van Hoof
spamfrommailing at freax.org
Sat Mar 5 16:05:24 EET 2005
After reading most/all reactions I'm going to wrapup my first
A generic configuration system that will be used by most desktop
applications. With desktop applications I mean that applications like
GNOME and KDE applications could use it. But also applications like
OpenOffice.org and Mozilla should have the ability to create a layer in
their configuration-codings to utilise this generic configuration
It needs to make it possible to "listen" for changes. Many applications
want to reload specific parts of their configuration by handling such a
"configuration key change" using a callback handler or callback
function. In fact this is the default design for almost every current
modern GNOME application. But not only that. Applications who are to be
ported to platforms and system where it's not the default to have such a
event-based configuration management, the system should also support a
transactional API. So that you can "Apply" and "Undo" a series of
For many other minimum-requirements please read the other posts. Most of
them are already implemented in the software "GConf".
What isn't needed or perhaps needed but not in the scope of a project
People have to understand that the "D" in D-Conf means "Desktop". Not
"Dude this can do everything". It's a Desktop Configuration management
system. It wont be started during the bootup of a computer system. It
shouldn't be used for system services like a webserver or an MTA. It
shouldn't be used to alter the tweak-settings of your kernel.
There's perhaps a few exceptions on that rule. For example the project
Eventually (please look it up) could read it's configuration from
D-Conf. Eventually aims to provide a GConf-like replacement for the
system services crontab and atd. Maybe in time this configuration-system
could be used for some specific configuration details of the X.Org
system. For example the per-user desktop resolution might be an
interesting configuration key/value to store in a system like D-Conf.
At this moment there's plenty systems and softwares available to convert
existing system-application configurations into a
database-with-triggers. There's no need to redo all this. Sure people
need it. But it isn't the desktop application developers nor the desktop
applications itself who are in need of it.
Also, D-Conf wont magically make system configuration easer to manage.
It will even put an extra needless layer on top of the current
situation. Neither the system administrators nor the desktop users are
in need of it nor want this.
The configuration of your bootup is mostly in hands of the packagers and
your distribution. In fact it shouldn't be alterable by a normal user at
all. And for that single case "configuring which of the system-services
are to be started upon startup" we shouldn't base an entire
configuration management system on the possibility to do that. There
easer ways to get that configurable by the user.
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg