Re: The technical rationale

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

> Alan Cox <alan redhat com> writes:
> > > Well, it happens that Gconf is a client-side wrapper for a CORBA server
> > > so, this is not really an argument. The discussion seemed to imply that
> >
> > The Gconf api is trivial to reimplement without the Corba crap but in terms
> > of X properties
> >
>
> It isn't X-bound - if reimplemented it would probably just use some
> cheesy custom protocol over sockets. Since I didn't feel like writing
> my own IPC hack I used IIOP instead, as implemented by ORBit.

Why does everyone wants his own IPC??

> My CORBA interface has all kinds of scariness in it though, since it's
> handling implementation details such as gconfd crashing and
> restarting, then restoring all the listeners that existed prior to
> crash.
>
> If someone was talking to gconfd directly via a cleaner CORBA
> interface, they would not get this robustness; when gconfd crashed
> they would just get a bunch of errors and their app's preferences
> stuff would stop working.

Wouldn't it be easier to use a persistent object reference instead. The clients
are then able to access the server as soon as it is restarted. Or isn't that
possible with CORBA/ORBit?

> Another thing handled by the GConf client-side code will be the issue
> of cache coherency, i.e. there's a client side cache, and I want to
> invalidate the cache for all keys in a ChangeSet prior to notifying on
> any of those keys. Again, if you were using the raw CORBA interface
> you'd have to do your own client-side caching, and deal with this
> issue yourself.

The plan is to use the "cache:" moniker for that (using the EventSource and
listening to invalidate notifications).

> So the client-side code is actually doing some work, it is not a
> gratuituous wrapper around the CORBA. This is work that is required to
> be on the client side, it can't be done on the gconfd side.
>
> This is why I suggested making bonobo-config a wrapper, because I
> didn't want to cut-and-paste the client-side code to handle these
> issues into the client-side Bonobo interface. Better to implement the
> client-side Bonobo interface in terms of the existing code.

reasonable.

> My suggestion for how to do bonobo-config the wrapper was to have it
> be an in-process component, so there would still be only one remote
> CORBA connection, and the only overhead of bonobo-config would be
> conversions to/from CORBA-typed values.

This is how it works ;-)

> If I ever removed the C API and replaced it with CORBA in GConf
> itself, I would not get rid of the current GConf.idl; that would
> remain as the connection to gconfd. Then I would have an in-process
> component interface which replaced the C API and had the code for
> server respawn, cache coherency, blah blah.
>
> So at that point you can see why bonobo-config as a wrapper is almost
> identical to bonobo-config as the native GConf interface, in my
> opinion. Because there is client-side implementation code in any case.

Yes, from the functional view. But if I look at the implementation I find things
like "union ConfigValue" which are totally useless (use CORBA_any instead).
Those things need a major cleanup.

> What bonobo-config the reimplementation does as far as I know is
> simply punt all the issues I'm handling on the client side and talk to
> the gconfd equivalent directly. I don't think that's really right.

We only define a common interface to access the data, but we can implement all
those features with this interface. Using the moniker "config:#cache" will do
that magic stuff for us.

> I think people have consistently been confused by the existence of
> GConf.idl and the fact that GConf talks to gconfd via CORBA. They
> think that because CORBA already exists at that point in the code,
> that is where any component interface must be placed, and that the
> CORBA interface there must be public. However, the gconfd server
> connection is a complicated, overoptimized, ugly thing you don't want
> to deal with.

Yes, but we also want an additional public CORBA interface for other reasons
(scriptability).

> A sane GConf component interface, like the current C interface, would
> be an interface to the GConf client-side functionality, not an
> interface to gconfd. It would contain implementation code that then
> happened to talk to gconfd and handle issues such as cache coherency
> and respawning.

> Since that implementation code is already in libgconf, and we need to
> support libgconf for backward compat, my recommendation has always
> been that bonobo-config the wrapper should be implemented in terms of
> libgconf.
>
> Because the sane way to implement bonobo-config the wrapper without
> cut-and-paste was to use libgconf, I saw no reason to include
> bonobo-config in GConf itself, it could just be a separate library.
>
> So that is the line of reasoning.  If anything there doesn't make
> sense, just say so. ;-)

Everything sounds reasonable so far ;-) All I want is to make the PropertyBag
interface the default way to get configuration data for bonobo/gnome
applications. That way we have a common interface for accessing PropertyBag and
configuration database values.

- Dietmar