On Sun, Nov 10, 2002 at 04:04:20PM +0100, Marc Mutz wrote:
> 
> I think it's more like keeping a central config server vs. each user 
> having it's config stored in $HOME. Some distributions are already 
> quite good at replicating a master install onto masses of clients, but 
> for the contral config server thing, LDAP and ACAP backends to KConfig 
> are very much needed. Making KConfig work for LDAP as-is (ie. without 
> needing to provide schemas for each app's config file) may be hard to 
> do, not sure if ACAP isn't as strict about this.
> 

The problem with ACAP is that there's only one implementation I know
of, and it's both unmaintained and written in SML or something.

If anyone is seriously interested in a server-based config solution, I
should point out that I'm willing to strip all the CORBA dependencies
etc. out of gconf, sync it to KDE release cycles in addition to GNOME
release cycles, rename it, move it to shared CVS, whatever it takes.
I wrote up some details on gconf and its role in this kind of central
config setup, see http://www.linuxsymposium.org/2002/ proceedings (I
think, haven't checked). The paper for OLS also contains some
discussion of ACAP.

Among the things this paper discusses is how you might go about an
LDAP-type (central server) solution, involving a local copy of the
config data.

To make sharing a config system implementation feasible, I think we'd
first need to solve the message bus layer (DCOP-equivalent). I'd be
willing to support a DCOP-compatible layer in the config system.

The config system significantly decreases in utility if some apps on
the system aren't using it, so working on a standard solution we could
promote globally might be cool. Of course the easiest way to get all
apps using a solution right now is config files over NFS.

While it's a nontrivial problem I don't think it's an insurmountable
amount of code; the gconf layer minus dumb cruft is 15,000
';'-terminated lines or so, and the message bus layer is probably
similar in size.

Cue "argh it's the registry" followup. ;-) (hint: go read the OLS
paper first)

Havoc