An analysis about a generic desktop application configuration management system

[Havoc Pennington]

On Fri, 2005-04-08 at 11:20 +0200, Philip Van Hoof wrote:
> 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).

Most LDAP servers have an extension for it you can dynamically check for
and use. IIRC there was a standard extension in progress at one point, I
don't know if it's been finalized.

This isn't very important, though. It's fine if changing the LDAP server
only takes effect on relogin or reboot. Dynamically taking effect is a
"would be nice" for this so it can be punted. Given a choice between
setting up a custom new server and losing dynamic change notification, I
think most admins would chose losing dynamic change notification.

>  And it's very likely administrators will interact with the LDAP
> server directly, putting the system out of sync.

It's OK if changes aren't seen until relogin/reboot.

> However. It will work together with existing ACAP implementations.

Except nobody uses ACAP. This is the most irrelevant feature I can
imagine.

Havoc