An analysis about a generic desktop application configuration management system

[Havoc Pennington]

On Thu, 2005-04-07 at 21:46 +0200, Philip Van Hoof wrote:
> 
> 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. 

Just make people deal with it on the client side, is my suggestion.

There's a much simpler approach to "transactions" than the usual
database sense of the word. For the keys involved in a "transaction",
tell the clients to invalidate any cached values, then make the
following guarantee:
 - if a client gets the value for one of these keys, it will be the 
   new value and not the old

Now, send out the notifications that the keys have changed. Clients who
care about a group of related keys will refetch the entire group and see
all the new values.

This is much more useful than rollback, because it lets e.g. the
gnome-panel see a newly-added applet (consisting of multiple keys in a
directory) as a whole.

> 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

See my other post.

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

I would not do this. Just use the scalability properties of the
enterprise server that you are chaining to. i.e. if you are using an
LDAP backend, the LDAP server will have replication. If people want to
put their workgroup settings on a file server, then they can use
clustered NFS.

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

If you compromise the user experience or make development more difficult
to comply with an abandoned, unused standard I just don't understand
that.

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

Maybe the diff fails to be maximally user-readable, but it works in
purely source control terms.

Havoc