Havoc Pennington wrote:
> 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).

I found it. It is in a PDF of 5.2 MByte, containing 631 pages of the
total proceedings. I have extracted the relevant 11 pages of Havoc's
contribution about GConf (it's only 60 kB of PDF now).

I have uploaded it to

    http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/GConf-at-OLS2002.pdf

Someone should grab it from there and put it onto a more prominent and
easy-to-find-and-remember location.

> 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

Cheers,
Kurt    [ delighted that this topic seems to tackled now... ]