Re: What will replace bonobo?

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Tue, 2005-03-22 at 16:19 +0300, Nickolay V. Shmyrev wrote:
> В Втр, 22/03/2005 в 11:47 +0000, Gustavo J. A. M. Carneiro пишет:
> > On Sun, 2005-03-20 at 08:16 +0100, Jean Bréfort wrote:
> > > Hi,
> > > 
> > > If I understand correctly what I read here and there, bonobo will be
> > > deprecated in a near future. I would like to know if there are plans to
> > > get a new component system for gnome to replace it and what technology
> > > it would use.
> > 
> >   I think the plan is to use D-BUS [1].  But it isn't ready/stable yet.
> > 
> >   Personally, I never liked this idea in the first place.  I'd rather
> > stick to Bonobo/ORBit2. 
> 
> Me too :)
> 
> >  However, it is a given fact that Bonobo has a
> > couple of hard to solve fundamental problems, and supposedly D-BUS will
> > have addressed these problems from the start. 
> 
> Oh that "hard to solve problems",  what are they? There are two main
> problem with it:
> 
> 1. Reentrancy (I think that it can be fixed, why not add locks to
> objects?)
> 
> 2. Easy GObject wrapping. It doesn't seems to be such problem,
> especially in 
> light of addition of scripting languages to platform. It really hard to
> imagine
> that new language will be also GObject-based.
> 
> 3. Political problems - bonobo have compromised itself, I don't know why
> and how.
> The main problem is that _some_ gnome developers don't like it.

  Yeah, I'm convinced only the following political reason, not technical
ones, are what's mainly driving D-BUS forward:

	1- RedHat wants to integrate KDE and GNOME better, no matter what.
Since KDE developers repeatedly refused to use ORBit2, and GNOME
developers wouldn't use DCOP either (thank god), the only solution was
to develop a new IPC mechanism acceptable by both desktops.

	2- As you said, there's a general FUD war against Bonobo, but it could
just be a consequence of the previous item.  Although I think developers
were already irked at CORBA from the past, mainly due to the reentrancy
problem and general complexity.

  That said, I see a couple of points in D-BUS that interesting to have:
	1- Security considerations from the start, allowing IPC between
processes owned by different users;

	2- Having a message based API available (perhaps below the RPC
framework yet to be developed) facilitates asynchronous message calls,
which is good for GUI apps, to avoid blocking GUI during RPC.

> 
> About DBUS it's hard to say that it will be replacement some day. First
> problem is
> that it's not component system, just message passing API. 

  Trust me, there are definitely plans to implement an IDL compiler of
some sort to imitate CORBA-style RPC on top of D-BUS messages.  It will
happen sooner or later.

  Even when the developers said D-BUS would not replace all bonobo (eg.
controls) at the time it was proposed, you just have to read between
lines to understand that this was only a temporary position to give
D-BUS a change to gain momentum.  Once most of D-BUS is implemented, it
will be a small step to implement a full component system on top of it.

> 
> What about implementation of CORBA 3.0 standards with ORBit codebase?
> That can give us new component system, rather powerfull and extensible.

  Yeah, that would be nice, but if the GNOME community doesn't agree
with this, then there is no manpower to implement this.  I for one
certainly don't have enough free time to have any noticeable impact on
such an effort.  Michael Meeks already has his hands full with
OpenOffice.org GNOME integration work (great work, btw).  We have to be
realistic: D-BUS has a ton of active developers, it will prevail in the
end, whether we like it or not.

  Best regards.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic