Re: Begun work on Bonobo IDL compiler

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

Well, BonoboUnknown is really a terrible name for the implementation.

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

My current thinking goes along the lines of: we need wrappers when
they do make sense.  But in some cases --and I am the one to blame--
the wrapper are sub-optimal and are downright pathetic.

> 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 agree with your first part of the message, but I am not convinced
that "learning" to use the client side C CORBA API is that terrible.
I do agree that having a GtkObject/GObject binding would be ideal.  

When I looked at it, I was convinced that it would required a
substantial ammount of work compared to what I am doing right now.
And I do not oppose this idea, I just think it is further down the

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

It is terrible yes.  But also keep in mind that internal C apis make
up for lousy CORBA exported APIs.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]