Requirements and pre-analysis for a cross desktop configuration infrastructure

[Philip Van Hoof]

Hi there,

I did a little bit research by reading mailinglists and even a little
bit of studying existing applications. Using the gathered information
I've tried putting together a compressed list of requirements for a
configuration system. Some of the requirements are probably duplicates
of something that already exists (yes, I know of the existence of
GConf). Others might make it bloat. 

I know it isn't by far complete. I know I still have to investigate lots
of other applications. In time, I will.

I did take a look at, for example, KConfig. Mozilla (and firefox) and
some GNOME applications. I haven't yet looked at the configuration needs
of, for example, OpenOffice.org.

I would be very thankful to software developers who append their needs
and or append thoughts to this document they might have about such a
configuration system. 

Once a version of the document is somewhat acceptable for most important
desktop applications; I'd like to propose putting it or another document
like this on the wiki of freedesktop.org.


Requirements
============

A configuration management  and  storage  system   that  can be used  on
multiple platforms (for  example Linux,  *BSD,  Windows,  Mac,  etc). It
needs  to  be  very  easily  to  integrate  existing  applications  and 
technologies with  it. Making this difficult will hinder the acceptation
by developers of existing applications.

It needs support  for  notification of key/value changes. This basically
means that applications  who  can  run  in a main-loop (so called, event
based applications -- most  applications with a userinterface --) can be
notified about configuration changes. A good example: when  you  change 
the global proxy settings in a KDE  application,  both  firefox  and the
weather-applet on your GNOME panel can easily take action on  behalf  of
that  specific event. Of course  only  in  case  those applications are 
interested in that specific event. There's  many applications  who share
interest in certain configuration  keys.  (Other  examples:  The default
applications to use like the default E-mail client)

In a future somewhere on the island Utopia  could  such  a  notification
system notify  panel  applets  and  other  applications about the screen
resolution  being  changed,  or  monitors  being  added to the dual-head
configuration. But perhaps are such events better handled by X11 signals
and atoms. I'm not sure a configuration system should be responsible for
notifying  applications  about  this  type of events. Whether it should,
needs investigation and lots of talking with the people involved.

It should support two types of  acknowledgment  of  settings:  Immediate
acknowledgment  on  a  per - setting  basis.  And setting  multiple such
settings in one action.  The  so  called  "applying"  of new settings or
setting a group of settings.

It would be nice to have some sort of transaction support.  But  so  far
I haven't  seen something  like this being used by desktop applications.
It can make it  more easy  for developers  to  create  so  called "undo"
actions and to make sure that a  group of settings  have indeed happened
before notifications are being send to interested clients.

Creating and restoring  offline  backups of the configuration-data  is a
must  have.  Applications  need  access  to  an  API  for exporting  and
restoring   their   settings.  Not  just some  commandline  tool.  Many 
applications    implement   dialogs   and   wizards (druids) to ease the
migration of settings to an other desktop computer. Or to let  the  user
store it's data and configuration on a removable device.

Some "geeks" use a source control system for managing changes  in  their
home directory. I don't see this  as a  required  something  to support.
Perhaps the  ability  to  freeze  writing  to the backend so that backup
applications  can  instruct the configuration daemon not to write for a 
certain amount of time or until the unfreeze command is given.

Some applications want the ability to "forget"  all  settings.  Therefor
deleting a  complete  tree  should  also  be possible using the API. For
example gnomemeeting has the possibility to reset your configuration. It
will, at this moment, try to delete the xml-files from the storage after
killing  the  daemon. It shouldn't  be  a  necessity  to do that. And we
should ask the gnomemeeting-team  why  it's done  that way  and  how  to
improve this situation for them.

$ gnomemeeting-config-tool --clean
...
Removing /home/username/.gconf/apps/gnomemeeting
Shutting down GConf daemon
$

It  doesn't  need  to  support  multiple backends out of the box. But it
should allow  the  creation  of  new  storage-backends. A  good  default
storage-backend can, for example, write  out XML files. The usage of XML
might,  however,  make  it  more   difficult   to   correctly  implement
transactions.

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 looks like GConf has support for read-only keys. But I  haven't  seen
it being used.

It needs support for some meta information per key. Like the description
and whether this is a default-value or a by-the-user set value. And  the
date it has been touched last time.

I'm not  sure  whether  it  should support saving  keys  when  they  are
overwritten (so that you can undo/restore the configuration to a certain
date). This might have a privacy (and security) impact.

Preloading all the keys from a specific directory-key in a library-cache
could  be  useful  because  most  applications  tend to  load  all their
configuration data at startup. This could  improve the  startup time  of
many desktop applications. Whether it will be significantly  improved by
such a enhancement should be investigated. It shouldn't, however, be the
default.



The current GConf system
========================

Advantages
o. Has notifications
o. Can use multiple backends
o. The daemon will be shut down after a certain amount of time

Disadvantages
o. Comes with only xml as available backend
o. Needs a daemon running
o. Is using ORBit-2, a CORBA implementation in C
o. Stores a list of connections of clients who are interested in 
   notifications
o. The build-environment needs some work

Nice to know
o. Depends on GLib
o. Depends on ORBit-2
o. Depends on libxml-2
o. Has a C++ wrapper

GConf's gconf-dbus branch
=========================

Advantages
o. Has notifications
o. Can use multiple backends
o. The daemon will be shut down after a certain amount of time

Disadvantages
o. Comes with only xml as available backend
o. Needs a daemon running
o. Isn't using the full potential of DBUS 
o. Stores a list of connections of clients who are interested in 
   notifications. with DBUS this isn't necessary anymore.
o. The build-environment needs a lot work

Nice to know
o. Depends on GLib
o. Depends on DBUS
o. Depends on libxml-2
o. Has a C++ wrapper

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