The technical rationale

[Havoc Pennington <hp redhat com>]

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.

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.

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.

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.

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.

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.

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.

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.

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. ;-)

Havoc