An analysis about a generic desktop application configuration management system

[Philip Van Hoof]

On Thu, 2005-04-07 at 19:44 -0400, Havoc Pennington wrote:

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

Afaik LDAP doesn't do notifications (but please correct me if I'm
wrong). And it's very likely administrators will interact with the LDAP
server directly, putting the system out of sync.

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

One author of an existing (free software) ACAP* daemon informed me (in
private) that the features a simple desktop application configuration
management system needs, are very easy to implement in ACAP. Doing only
those features won't make it a full blown ACAP implementation nor will
it be conform to the IETF standard.

However. It will work together with existing ACAP implementations.

Also note that there is an ACAP client API available*. I haven't deeply
investigated this. However, the idea is not to create an ACAP-server
implementation. 

The idea is to make (in a plugin thats deactivated by default) every
conductor (thats the daemon) an ACAP-client. And to let it retrieve it's
local cache of persistent configuration data from such an ACAP source.

After that it might be interesting to take an existing opensource ACAP
implementation, and to make that implementation more D-Conf aware.

I do understand that all this is a lot of work. But many hands make
light work. We simply need to agree on the specification and get people
interested in implementing this. Agreed and I'm fully aware of it thats
the most difficult part of the game.

* http://asg.web.cmu.edu/acap/index.html
* ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/cyrus-acap-api-c-v1.a2.tar.gz


ps. About UniConf: Avery, for a starter. Don't use sentences like "Your
Config System Sucks" in presentations like uniconf-presentation*. None
of the systems mentioned suck. They all serve(d) a purpose. You are only
pissing off exactly those people who you'll need to get your system
accepted. In all honesty I'm not convinced UniConf is a real candidate
here. But please feel free to, in a humane way, prove me wrong on the
D-Conf wiki I've put online.

* http://open.nit.ca/uniconf-presentation.pdf


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