Re: D-BUS enabled GConf available
- From: Owen Taylor <otaylor redhat com>
- To: Michael Meeks <michael ximian com>
- Cc: Mikael Hallendal <micke imendio com>, Christophe Fergeau <teuf gnome org>, D-BUS List <message-bus-list freedesktop org>, gconf <gconf-list gnome org>
- Subject: Re: D-BUS enabled GConf available
- Date: Mon, 08 Dec 2003 10:35:02 -0500
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
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.
] [Thread Prev