An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 15:16 -0400, Havoc Pennington wrote:

Hi there Havoc,
 
In my reply I'm not trying to make statements like: "you are wrong
here" :-). Many times I'm explaining in my reply "why" it's written like
this (at this moment, because it's a wiki and people are free to improve
it themselves).

Also note that I'm not excluding the chances of GConf being used to
build the generic desktop application configuration management system.
GConf is a very important piece of software. It does have it's issues,
but that doesn't mean that it's worthless of course :p.

> I think you should dump the transactions requirement. It seems like it
> should be useful, but in practice nobody has this and apps all work
> fine.

Some of the applications that we looked at needed some sort of "undo"
functionality for specifically their "preferences". In order to
correctly undo preference setting actions, it feels right to have an
atomic system with rollback functionality. 

Using an atomic backend (like SQLite), it will be more easy to implement
such a "undo"-feature. However, whether such a feature is really a
requirement is something to investigate more deeply.

> >       * There's a need for a default backend database format that can
> >         store Unicode data in a tree-like structure or in a structure
> >         that emulates a tree. 

> If you dump the transactions requirement you can go back to text files.
> Using simpler text files is the major reason that KConfig is better than
> GConf for system administrators, so text files are a significant plus.

The support for text-files can also be available in the form of a tool
to extract and import text-files from the system. I'm not yet convinced
why the default and internally used backend data should be humanly
readable or usable by external applications while the configuration
system is running.

In my humbly opinion it only serves for the purpose of keeping the data
persistent between sessions. I (we) would implement this making it
possible to get the data in a humanly readable format, using both a tool
and an API for this.

Such an API seems necessary for tools who want to do version management
with the configuration data. Or for integrated backup-applications. One
of the previous  lengthly discussions on this mailinglist concluded
that.

> >       * The system should be network transparant and an IETF protocol
> >         for configuration access would be nice. 

> I don't think this is important. You might want a network backend
> eventually, but the only network communication needed is for the backend
> to go out and fetch settings. You don't need network transparency
> anywhere else in the system.

Indeed. The idea is (of course) to connect the daemons with each other
rather than having one daemon on the entire network. So in a way we want
it to make it possible to let one daemon act as the backend for another
daemon. And create chains of daemons to scale the configuration
management to large quantities.

We aren't sure about ACAP yet. I have investigated it but ACAP actually
has to much in it's specification to support. It might be overkill.
Nevertheless it's nice to support a standard rather than creating a new
one for the same purpose.

It looks like ACAP was created to make configuration management network
transparant. Therefor we'll at least need to take a look at it. Perhaps
there's a few good ideas in it. Perhaps ACAP is indeed usable.

> IETF protocol is useless. Widely-used protocol people want to use, maybe
> LDAP, could be useful.

LDAP is another candidate (not yet written on the wiki-document, feel
free).

> >       * The system should be integratable with source control systems
> >         or other external tools for doing version control
> 
> If you use text files you can get this free.

I'm not convinced that it will be more work to create both a backup and
restore tool and an API for getting the data in a humanly-readable
format, than it will be to write this daemon using plain text files as
the default backend.

Note that XML isn't suitable for source control systems (using diff on
it is difficult and often fails).


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