Re: Begun work on Bonobo IDL compiler

[Maciej Stachowiak <mjs eazel com>]

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

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

This brings up an interesting side issue - I think the name difference
between BonoboObject and Bonobo::Unknown is gratuitous and
confusing. How about renaming one or the other.

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

It's true that hiding error reporting from the caller is bad, although
personally I'm not sure passing up the CORBA_Environment is the best
way to handle things.

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

Maybe I'm confused by the fact that many classes are client/server
pairs (for instance BonoboControl and BonoboControlFrame).

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

Are you suggesting that the current bonobo client wrappers should be
removed? Or that new ones should not be written for new interfaces
implemented in Bonobo or elsewhere?

I agree that an incomplete, leaky wrapper like the current client
wrapper code is bad, but I emphatically disagree that any kind of
wrapper is useless. I think it would be terrible if all GNOME
developers had to learn two different object models, Gtk and the CORBA
C mapping, to use GNOME effectively.

I also think it would be terrible if, when converting an ordinary
class in a Gtk/GNOME project to a component, you had to completely
rewrite all the client code to use CORBA style access instead of Gtk+
style.


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

You're right, but that wasn't my point; I was trying to point out that
you get a raw CORBA object when you query_interface and must create
the wrapper object 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 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.

My idea is that with a gtk binding, you don't need
CORBA_Object_duplicate, you just use refcouting on the GtkObject.

If GtkObject lets subclasses hook into the refcounting (if it doesn't,
maybe I should request this for Gtk/Glib 1.4), it could also solve the
confusion between gtk_object_ref and bonobo_object_ref, another thing
that has come up here.
 
> > 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.  

OK, I feel a bit better about this, then, although I still think it
would be better to put work into a more complete solution.
 
> 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.

Does that mean it would be valid to consider such calls bugs, and add
them to the IDL where appropriate?
 
 - Maciej