D-BUS enabled GConf available

[Owen Taylor]

On Mon, 2003-12-08 at 17:57, Michael Meeks wrote:
> Hi Mikael,
> 
> On Fri, 2003-12-05 at 23:27, Mikael Hallendal wrote:
> > * The CORBA-version has always had a problem with not dying together 
> >   with the session (still doesn't) which means you have problems if you 
> >   login from several locations (for example in a thin client setup).
> 
> 	Well; the odd thing is - we have a client using umpteen thin clients in
> anger; they have a 'blade' setup, whereby eg. they run evolution on 1
> blade, galeon on another, nautilus on another - and (I assume) this
> rather relies on GConf's network transparency in order to keep settings
> coherent.[1]

In real experience, GConf's current network transparency is a disaster
not because of problems with the usage of CORBA, but because of the
ad-hoc nature of it. Just because workstation A and workstation B share 
the same home directory doesn't mean that workstation A can access
arbitrary (or any) network ports on workstation B. So, if the GConf
server happens to start up on workstation B because the user logged
in there first, then the user can't use GConf on workstation .

Solving this almost certainly requires going to a standard model 
where there is a dedicated "configuration server" for the workgroup;
then system administrators just have one more instance of a problem
they've solved dozens of time before.

For your current "blade" setup, the current GConf network transparency
may work, assuming that you trust the authentication  bits of ORBit.
But I doubt anybody is really happy with a random distribution of
gconfd's across the blades. And it isn't a general solution.

The D-BUS protocol isn't limited to local network connections, so a
D-BUS based protocol could certainly be reused for the central server
as well as a CORBA-based protocol, though perhaps neither is right.

Regards,
						Owen