An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 15:44 -0400, CHonton at xteric.com wrote:

> > 
> > This shouldn't be a problem. If you use a database you should have 
> > utilities to import/export xml files from Stdin/Stdout.  
> 
> The point is that the proposed system is so complex that: 
> 1) It may never get written. 

Oh. I wouldn't say that. I don't think it's complex. We (the opensource
free/software communities) have created far complexer softwares. And in
my humbly opinion this is a core component of the free desktop.

> 2) It may never get adopted. 

Getting people to accept and adopt it, however, is indeed the difficult
part. But thats (in my humbly opinion) not because it's complex. It's
complexity might have an impact on the amount of bugs (which will in
turn might impact the acceptation). I think whether or not a few major
applications adopt such a new system (once it's build) will play a far
greater role for the acceptation.

Therefor I kindly invite the authors or the larger applications to
append their comments and ideas to the wiki. Perhaps even play a role
during the implementation.

> Start with the basics.  What is the minimum set of requirements before
> KDE and Gnome will use DConf?  Implement this minimum set.  Prove that
> the minimum set works with a test suite.  Get the minimum set adopted
> by the desktops and applications.  Then, and only then, start working
> on the whizbang features. 

What has been written on the wiki are the basics. It's not trying to be
crazy in the quantification of features. When you merge the current
available features of GConf with some of the requirements that have been
posted here, you'll get that list. KDE wants to enable kiosks to use
this. Large organisations want network transparency, ACL's and hope to
one day have the possibility to do version management with the
configuration data. GNOME wants change notifications. Etcetera ...

> The minimum set is probably a lot less than you might think.  My
> belief is that transactions, stackable back-ends, and notifications
> are not required in round one.  Round two might see notifications.
>  Various back-ends can be adopted as needed at particular sites, but
> distributions are going to want to use a simple storage mechanism. 

I agree that stackable backends are not required in round one. But I'm
confident that the support for change-notifications is (all GNOME
applications depend on this). I'm not sure about transactions. We we
should keep some things in mind in order not to restrict our
possibilities for future releases.


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