Re: Begun work on Bonobo IDL compiler

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel@helixcode.com> writes:

> Hello guys,
> 
>    I have begun the work on the bonobo idl compiler that should
> simplify the development of Bonobo::Unknown based objects.  
> 
>    In the past I have told people about creating a Gtk-based CORBA
> bindings and using this instead of the C bindings, but after a lot of
> thinking and discussion with other people, I have reached the
> conclusion that it would be a useless excercise.
> 
>    See, you can think of the functionality provided by Bonobo CORBA
> servers as implemeneted in bonobo/bonobo as pre-done implementation of
> common interfaces, with a good portion of sugar coating to simplify
> the development of Bonobo applications.
> 
>    Although this addresses a large problem and simplifies the life of
> most developers interested in the the traditional uses of Bonobo, the
> development of Bonobo servers typically contained a lot of boiler
> plate code and there is a very little motivation for making those
> interfaces a layer of sugar candy, as they would typically be final
> implementations.
> 
>    So I have decided to keep the CORBA C binding and instead just
> simplify the authoring of Bonobo servers.  Clients would still have to
> use the CORBA C binding to talk to the servers, and the servers would
> still use the C CORBA API for transfering information back and forth,
> but the ammount of work required should be drastically reduced now.

Can you explain how your planned IDL compiler would help? Some of the
most annoying things about creating a new interface, or using custom
interfaces right now are:

1) You have to deal with the POA directly when implementing the
   server, and this is ugly; there is much ugly code around to
   properly construct vepv's for objects that implement Bonobo
   interfaces.

2) Conventionally, you write a GtkObject wrapper for the server
   implementation, this is a huge mess of boilerplate code often
   containing weird mixes of direct CORBA C mapping calls and wrapper
   calls.

3) Conventionally, you write a GtkObject wrapper for the client,
   rather than forcing the client to use the stubs directly, since
   that would be ugly. But these client-side wrappers are all
   boilerplate code.

4) When you query_interface for a custom interface, you get back a raw
   CORBA_Object, not the appropriate client-side wrapper class. So to
   use the convenience wrapper, you need to have linked in the code
   for the client wrapper, know what the wrapper class is, and do the
   wrapping manually. 

5) Because the CORBA_Object layer leaks through the bonobo wrapper
   API, sometimes you must write application code that intermixes
   both, which leads to very confusing code. For instance, developers
   here at Eazel have asked me many times to explain when you should
   use CORBA_Object_duplicate, when you should use Bonobo_Unknown_ref,
   and when you should use bonobo_object_ref.

I think a GtkObject CORBA mapping could address all four of these
problems (I'm not sure, I don't know the details). It sounds to me
like your proposal does not, although I admit I don't understand
clearly what it would do.

Could you tell me why you think a GtkObject binding for CORBA wouldn't
actually solve these problems, or why they are not worth solving, or
better yet, how your proposed thing would solve them? :-)

Another annoying problem is that useful API calls for many interfaces
are actually implemented in the libbonobo wrappers, and not expressed
at all in the IDL, which makes them inaccessible to anyone trying to
use the CORBA interfaces directly (which I presume would happen for
scripting langauges, or else you'd need a special language binding for
every Bonobo interface defined, which misses part of the point us
using CORBA in the first place). OAF and GConf have this problem too
to some degree.

I think using a GtkObject CORBA binding could drastically reduce the
temptation to do this, and instead lead to having the IDL describe the
complete, actual interface that all applications and languages get,
the way it works with COM.

It seems to me that making the IDL the only thing you need to fully
use a component is the only sensible way for a component model to
work.

 - Maciej