Re: [gtkmm] Bringing Bonobo to the masses :)

[Havoc Pennington <hp redhat com>]

Paul Barton-Davis <pbd op net> writes: 
> I am generally very troubled by the slow emergence of a s/w
> infrastructure that is composed of the kind of complex library
> inter-relationships that GNOME is building. I feel very confident that
> this is a design error, and will lead to many headaches down the
> road. 
>

I have already started a few huge flamewars pushing this point of
view. Modularity good. Huge spaghetti mess of dependencies bad. ;-)

There are some things we can do and in some cases are doing:

 a) minimize interface dependencies between libraries/modules (don't
    leak XML/CORBA implementation details out of the GConf API, for
    example, despite using libxml/ORBit internally), so you can have
    future flexibility.

 b) a special case of a) which is component technology; typically
    components expose _no_ interface dependencies, though they 
    can from time to time it's generally easy to avoid.

 c) a special case of b) which is using component technology 
    to avoid writing language bindings all the time; 
    i.e. we have no library to go with components, just 
    use the components directly using the CORBA bindings for 
    a given language. This is how Microsoft supports 
    multiple languages.

At the moment c) requires wrapping the C implementation of Bonobo
in each language before you can use components for all 
the other stuff in that language. So the Bonobo binding is the base
binding you need to avoid additional language bindings.

It does seem like we could avoid this in the spirit of ORBit, where a
number of routines appear to be CORBA calls (have IDL, follow CORBA
language binding conventions) but are in fact just in libORBit. At
least, that is my impression of how things are implemented.

In practice I'm not sure if that's the best solution, certainly it
isn't the one the Bonobo guys decided on so there is likely some
reasoning there.

Havoc