DConf: some observations

[Simon Edwards]

Hello,

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 
classroom."

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' 
problem.

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."