Re: The technical rationale

[Dietmar Maurer <dietmar ximian com>]

Havoc Pennington wrote:

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

Well, I know how it works. And fortunately we already have the "gconf:"
moniker ;-)

- Dietmar