[Mono-list] Mono and Bonobo

[Michael Meeks]

Hi Andy,

	You ask a very good set of questions, so I'll cross post the
answer if I may to gnome-components-list.

On Thu, 9 Aug 2001, Andy Tai wrote:
> Hi, this is more a GNOME question than Mono question, but one has to
> question it.  Ximian is the major force behind Bonobo, the GNOME
> component framework.

	Right,

>  Bonobo has just passed 1.0 and not many people outside Ximian are
> using Bonobo yet, although Bonobo has the promise to revolutionarize
> Unix (Unix-specific!) applcation development.  Bonobo, being more low
> level and C based, does not provide the kind of cross-platform
> functionalities JavaBeans provide, or .NET provides.

	Well whilst clearly bonobo bindings for Windows are not
reasonable, there is no reason why we cannot use map a .Net API to use a
Bonobo component based implementation.  Alternatively we can have native
bonobo bindings - extending the Mono API.

> But now Ximian is havily pushing Mono, which I assume has (or will
> have) its own component architecture kind of like JavaBeans rather
> than COM or Bonobo.

	Well - while clearly Mono will need some sort of component level
bindings - I envisage that in many cases they will merely be thin wrappers
around the equivalent Bonobo interfaces mapping to the standard MS
equivalents. Either way - no work has been done in this area as yet.

> Ximian did state that Bonobo and Mono can be connected via bridges,
> but that will have more overhead (for applications) compared to, say,
> native Bonobo applications.

	Ahh; now is that true ? :-) You see, my feeling is that in the
long run we need to move to a more hetrogenous language environment, away
from low level languages. I also think that many of the problems we try
and solve (badly) in ORBit2 and glib-2 (CORBA_TypeCode, GValue, GType
etc.) would best be solved 'right' at a common bottom layer by building on
something like the Mono CLR type / allocation infastructure. I furthermore
think that backwards compatibility is vital, and that feasibly large
applications will still need some parts written in C, using Bonobo for
speed - for some time to come.

	However - my real point is that a bridge is not neccessarily slow.
In ORBit2, for the first time we have infastructure in place that will
allow extremely fast in-proc bridging to the ORBit type system ( very
useful for scripting bindings too ), and full interface and type
information rapidly available via dyamicaly loaded type libraries. So, we
have a huge amount of potential here for extremely quick bridging to other
component systems - particularly this was implemented to make UNO bridges
possible, but Mono is just the same. In fact - the performance cost of
bridging is equivalant computationaly (if not less) to that of marshaling
/ de-marshaling the data to a GIOP format.

>  Just as Bonobo is ready for the world, Ximian switches the focus or
> mindshare to the .NET architecture.  One has to worry if Bonobo will
> be set aside, and application developers who would have used Bonobo
> would now jump to Mono.

	Well - I can assure you that I'm not setting bonobo aside, and
neither is Ximian. In fact, in Gnome 2.0; where bonobo finaly comes of
age, the use of bonobo is extremely far reaching, monikers are used
extensively - ( eg. for every configuration option ) and we will be
encouraging and helping application developers to componentize and move
their apps / [c]applets to the bonobo world.

	So really - I think the only issue is; that we need more people
hacking on / porting to Gnome 2.0 - where libbonobo is approaching the
foundation of the dependency tree.

> GNOME needs Bonobo in its competition with KDE's KParts (or whatever
> it is called these days) for the dominance of Unix desktop, and for
> Unix's desktop expansion against Microsoft. But one has to wonder if
> Bonobo will go the way of OpenDOC, which IBM dropped in favor of
> JavaBeans.

	As you say, we need to concentrate on getting our compound
document code up to scratch, and if this is an area that interests you
it'd be great to have someone working on the bonobo canvas code; talk to
Mike Kestner about it. However, again in gnome 2.0 we've put extensive
effort into re-writing the compound document interfaces, removing cruft
and making them more viable.

	So ... ultimately the conclusions are:

		* Bonobo is not dead, or deprecated
		* We need more hands / eyes on Gnome 2.0

	Does that re-assure you slightly ? I think that the Mono
technologies can only be helpful to the increasing componentization, and
role of bonobo in the year to come, and that the infastructure provided
will be most helpful for gnome technologies.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot