Requirements and pre-analysis for a cross desktop configuration infrastructure

[Philip Van Hoof]

On Thu, 2005-03-17 at 11:37 +0100, cobaco (aka Bart Cornelis) wrote:
> On Thursday 10 March 2005 21:15, Philip Van Hoof wrote:

> > The backend  needs to support default settings which are stored on a for
> > the users  read-only  location. For  example: the  user  settings go  in
> > $HOME/.dconf/ and the defaults go in /etc/dconf/default/.
> 
> it needs more then that: 
> - it needs what kde calls 'cascading configuration', i.e. multiple 
> configuration sets that can be stacked, and activated conditionally (say 
> one set of configuration for admins, one for management, and one for 
> ordinary office workers, stacked on top of common base-settings)

That means that you need to add some sort of meta-information to the
user-accounts of the system that tells what type of user it is? Can we
keep this platform independent? How will we do this platform-transparant
on different desktop-systems? Windows, Linux, etc?

> -> the basedir spec provides for the stacking

> merging of the different configuration sets should with be done with a 
> granularity of individual settings (not config files). And ideally there 
> should be a mechanism to mark settings as can't be changed by user (similar 
> to kde kiosk system)

Okay. I can see a use for that. So far I haven't seen applications that
heavily depend on read-only -ness of configuration keys. But I can
imagine that some distributors like to create such configuration-keys as
read-only and not-by-the-user -over writable. Of for, indeed, kiosks.

> NOTE: gconf supports the above though somewhat hackisly:
> - for the conditional activation of what gnome calls 'configuration sources' 
> you need to generate a path file on login AFAIK, which I find rather ugly
> - any locking of settings needs to be done by splitting out the locked 
> settings into a separate 'configuration source', which needs to be 
> carefully ordered in the path file to be looked at before the user 
> settings, which makes it a pain to switch things from mandatory to 'may be 
> changed'


GConf is a very nice configuration system by itself and it does support
most of the requirements a very good configuration system needs.

However

The more I read and study the GConf code and overall design, the more I
start feeling that at least lots of it will need to be redesigned and
rewritten. Only to correctly get rid of the current ORBit-2 dependency,
one would need to get a huge patch approved by the current GConf-team.
And by huge I do mean huge (as in, more than 50% of all it's code will
need to be rewritten AND redesigned).

I think (and when I start saying "I think" it means that I'm talking
about my personal opinion, so by definition no longer about facts) we
should take the experience GConf has created, merge it with the
experience of KConfig (and perhaps other configuration systems like the
Windows registry) and rebuild a D-Conf upon that experience.

I've already found two experienced C developers who are willing to, with
me, actually start coding such a project. We already have drawn some
API. We do understand that this isn't enough. We need acceptance, more
analysis and use cases.

And I'd really hate myself for creating yet another configuration system
that wouldn't be widely accepted. That would show the corporate world
that the opensource/free software development model just can't work
together on such things. I'd really really really prefer that multiple
existing and important parties would be involved in the system that I'm
proposing here.

Else there's really no use for such a system. Else we are much better
off supporting the existing situation of multiple configuration systems.


Nevertheless, thanks a lot for your input on this subject.


-- 
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
http://www.freax.be, http://www.freax.eu.org