Re: Begun work on Bonobo IDL compiler

[Miguel de Icaza <miguel helixcode com>]

A lot of the confussion comes from a historical development of Bonobo:

	1. Bonobo simplified the creation of Bonobo::Unknown servers
           and established a framework for inheritance of code in
           implementations.

	2. Bonobo simplified the aggregation of independent interface
           implementations by using the BonoboObject.

	3. Bonobo provided sample implementations for a number of
           servers that was easy to reuse and used signals to notify
           people of interesting events.

	   This is mostly used to quickly implement things without
	   having to subclass Gtk objects. 

So far life was good, then the problem was a new addition to Bonobo
land which tried to simplify the client side.  In many cases it made
sense, but in others, the -client.c code was just a plain wrapper for
the CORBA C call.

These wrappers typically have hidden the CORBA_Environment from the
caller, which is a terrible thing to do.  

So, with very few counted exceptions, I think that the -client.c code
is not incorrect, but ugly and extra gracious bloat

Given this little background, I am going to reply to some of your
concerns.

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

It is very simple, and the repetitive parts are going to be
implemented by Bonobo idl compiler (indeed, I think this is one of the
few things already written).

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

I think you are confused.  Server implemementations barely use the
GtkObject/CORBA_Object mix.  It is mostly the clients that get the bad
treatment.

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

Those are sugar candy, and they very seldom make sense.  Sometimes
they do, but on average they dont.

My current work is focused on simplifying the development of servers,
and assuming that clients will mostly do fine by using the CORBA C API
to access the servers.

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

I believe we have changed this recently to be Bonobo_Unknown instead
of CORBA_Object.  

> 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 agree this is a problem, and I am now thinking that wrapping the
client side is of limited use.

Now even with a native Gtk bindings, fixing the problem between
Bonobo_Unknown_ref and CORBA_Object_duplicate is just not going to
happen.  It will fix part of it (CORBA_Object_duplicate vs
bonobo_object_ref), but again, if we drop entirely the _client stuff,
we solve this.

> 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? :-)

A GtkObject binding would be a much nicer thing to have, but it is a
more complicated problem than the one I want to solve now.  

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

You are partially right.  To be honest, I can think of very few
internal function calls that are really not CORBA exposed that we
would like to have.  And the problems we do have are more
infrastructural problems (like our sub-stupid and sub-optimal Moniker
implementation) than the fault of the binding.

> 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 would, yes.

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

yep.

Miguel.