Re: The technical rationale

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

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

That would be a nice implementation detail ;-)

> > > 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 know. But it works now and we can use it.

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

You always say that a clean implementation is worthless. I cant agree on that,
and I think it is very important to maximize code reuse.

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

What if you decide to not maintain it any longer??

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

Everyone has it own 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.

We use "config:" as moniker name.

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

Yes :-)