Re: The technical rationale

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes: 
> Why does everyone wants his own IPC??

I don't, that's why I used CORBA in the first place.
 
> 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?

I have no idea if it's possible. It might be a nicer way to do
it. Fortunately the implementation details of this are concealed, so
we can do it that way sometime.
 
> > 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 ;-)

Good!
 
> 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.

It's a totally concealed implementation detail that exists because
CORBA_any did not work when I wrote that code. I tried to use
CORBA_any, Elliot said it wouldn't work and was hard to fix.  Remember
I was writing this nearly two years ago. Bonobo didn't even exist in
remotely usable form at that time.

I don't see how it makes any difference at all whether it's changed at
this point. It would break compatibility of new gconfd with old
libgconf-client, and would just not offer any user- or
programmer-visible enhancement. All pain zero gain. It's hardly a
justification for reimplementing the config system.

There is this concept of "implementation detail concealed by the
interface." ;-) Maybe you've heard of it. Anyhow, said implementation
details only matter for maintaining the code. And I'm maintaining the
code so it's my problem. You really could spend your time on doing
something else! There are so many things that need doing and this is
not high on the priority list.

If I need to break the interface for some other reason, I'd probably
take the opportunity to clean this up. But it's pointless pain to
break it purely for this, since it's just internal cruft. Who gives a
damn? It has no practical impact _whatsoever_.

You see a nice CORBA_any interface with your wrapper, OK, so that's
all we need to know.
  
> > 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).

I agree. Look, my point is simply that GConf.idl is a TOTALLY
DIFFERENT BEAST from your interface. It makes no difference. There is
no relationship between my ConfigDatabase CORBA interface and your
Bonobo::ConfigDatabase. Yours is a client-side API used by apps. Mine
is an implementation detail of talking to the daemon, used by
client-side library implementations. They are not analagous. They are
not the same. They are in no way comparable. As far as you're
concerned, ONLY the C API for GConf exists. You do not even need to
know about GConf.idl. If the code was proprietary, you would never
know it even existed. It is inside the black box. It is behind the
client API. I am repeating myself more times than Mojo Jojo. ;-)

If I were going to write a client-side component interface, it would
be like Bonobo::ConfigDatabase, not like GConf.idl.
 
> 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.
> 

Yes, that's fine. All I want is for apps to use the moniker that wraps
GConf. And I'd suggest a generic moniker name such as "defaultconfig:"
or something instead of "gconf:" so we can swap out different config
implementations later, and app developers don't have to care about the
backend.

Anyhow, I think we are in agreement at this point.

Havoc