DConf: some observations
simon at simonzone.com
Wed Apr 13 22:57:17 EEST 2005
I've been following this discussion this week and just wanted to make a couple
of points that no one seems to have missed.
1) The discussion so far has been *very* technological and implementation
driven while the real world problem(s) that need to be solved have barely
been outlined or discussed. I'm not talking about things like "must support
transactions" or "run as a daemon". I'm talking about mundane real world
scenarios / Use cases such as:
"Administrator Alan runs a classroom of computers, setup with Kiosk etc. Alan
wants to disable printing in the web browser for all of the computers in the
or the most common case (95%)
"User X sets option XYZ in KApp. KApp should remember the state of XYZ next
time it it run."
Without a clear idea of the problems that need to be solved you might sitll be
able to make a configuration system, but its usefullness in the real world
will have less to do with engineering and more to do with dumb luck. The
needs of the applications built on top of DConf (or whatever), and their
problems, are the most important things to think about first.
Later, with a clear idea of what needs to be possible you can work out the
technical details. (This seems obvious to me, I don't know why everyone is so
keen to spark emacs up at this early stage.)
2) Speaking as someone who actually is working on GUI system configuration
tools, and not a wishywashy 'framework', I can safely say that the many
configuration formats are definiately *not* the reason why configuration on
Linux is difficult. Writing a wrapper/library for handling a particular
format is the super easy part of developing a config tool. Really people,
it's a CompSci 201 homework assignment.
The killer is semantics. What the hell *do* you put in the config to get what
you want? What are the different options and settings? What are the
acceptable values? What do these different settings mean? How does this
setting interact with the others? Answering these questions and then devising
a useful GUI/application on top is where the real work is. Reading/writing
file formats is less than 10% of the work.
I'm not saying that an API/protocol/thing like DConf wouldn't be useful. I'm
just saying that it is a relatively small part of the bigger 'configuration'
Better standards and documentation about what can go in many of the
configuration files on a system would be more useful.
thanks you for your time,
Simon Edwards | Guarddog Firewall
simon at simonzone.com | http://www.simonzone.com/software/
Nijmegen, The Netherlands | "ZooTV? You made the right choice."
More information about the xdg