Re: The technical rationale

[Havoc Pennington <hp redhat com>]

Hi,

To point out one more thing, let's go back and look at the issue of "C
API elimination" in light of the analysis I've just given.

So we have my suggestion for a component interface wrapper, which is:

   gconfd <-> libgconf-client <-> component interface <-> app
           A                   B                       C
   
Connections A and C go via CORBA. B is a non-component API. CORBA
interface C uses the non-component API B in its implementation. 

So now let's look at bonobo-config as reimplementation:

  backend code +
  libonobo-config <-> component interface implementation <-> app
                   D                                      E

D is a noncomponent API, E is a CORBA interface.

So you see that in both the bonobo-config as wrapper and bonobo config
as reimplementation, we have a noncomponent C API which is used to
implement the component interface. In neither case do apps talk to C
APIs, in both cases the component implementation uses a C API as an
implementation detail.

Now in my scenario you do have two CORBA interfaces (though you could
in the second scenario as well, in the "backend code" handwaving
box). However, if having two CORBA interfaces involved in a codepath
dooms performance, I think we have a more general problem. And for
in-process components I don't think two interfaces will doom
performance.

Havoc