Re: Few questions about Bonobo

[Michael Meeks <michael ximian com>]

Hi Philippe,

        Some good questions indeed, let me try and answer them:

On Thu, 27 Sep 2001, Philippe FREMY wrote:
> I read that you can have an in-process server for components ? That
> just rocks. I'd like to know more about this.

        Ok - the in-processness is relatively transparent to the server [
server = the frame, or application activating the component ], ie. you
just do:

        bonobo_widget_new_control ("OAFIID:GNOME_Foo_bar");

        eg. And if it is a shlib component it is linked in dynamicaly and
the component created from the factory and returned to you. If it is a
remote component, then a remote process is forked, the factory registered
with the object naming service (bonobo-activation-server), and it's
reference passed to you. In both cases you get an opaque Bonobo_Unknown
reference that might be to a local or a remote component.

> Do you have to develop your component especially for in-process or
> out-of-process server ?

	It is something that you need to bear in mind in a few
situations, here are the few points:

	* With a remote process there is implicitely more concurrency,
	  thus you can have several things happening at once, this is
	  both a blessing and a curse:

		+ you can use 'oneway' methods, and get asynchronous
		  communication, and an illusion of threading, while
		  being single threaded.

		+ you can use that 2nd processor, and get performance
		  wins

		- you can get re-entered at the drop of a hat, and
		  much code is not re-enterancy safe, indeed it takes
		  thought to make it so.

	* 'oneway' methods don't block talking to a remote process,
	  but they do talking to a local one - since flow is handed
	  straight to the other component.

	* A few easoteric CORBA features such as the '_release'
	  optimization which works really well for making returning
	  large datastructures without allocation thrash feasible
	  cause serious lifecycle grief in-proc and are only suitable
	  for out of proc.

> How do you select which kind of server will be used ? If you can use
> in-process components, when does it make sense not to use it ?

	Well - because of the re-enterancy issue, we select in-proc
components for small GUI things often. For compound document things,
and cases where we want to abstract complexity and dependancies (
eg. a gdb wrapper ) we go out of proc, simply because we don't want
that scale of breakage / dependency in-proc :-) Also, having things out of
proc is far better for stability - if a client process dies the server
just carries on.

> In KDE, we use in-process components everywhere. There are only very
> rare case where it doesn't make sense (more precisely, it is not
> possible).  I imagine that when calling a function, there is still a
> conversion: component host types -> idl types -> component types no ?

	Nope - when you call a local method in Gnome 2.0 you pass your
types to the stub eg.

Bonobo_Canvas_ArtUTA *
Bonobo_Canvas_Component_update(Bonobo_Canvas_Component _obj,
			       const Bonobo_Canvas_State * state,
			       const Bonobo_Canvas_affine aff,
			       const Bonobo_Canvas_SVP * clip_path,
			       const CORBA_long flags, CORBA_double * x1,
			       CORBA_double * y1, CORBA_double * x2,
			       CORBA_double * y2, CORBA_Environment * ev)
{
   Bonobo_Canvas_ArtUTA *_ORBIT_retval;

   if (ORBIT_STUB_IsBypass(_obj, Bonobo_Canvas_Component__classid)) {
      ORBit_POAInvocation _invoke_rec G_GNUC_UNUSED;

      _ORBIT_retval =
	 ((POA_Bonobo_Canvas_Component__epv *)
	  ORBIT_STUB_GetEpv(_obj,
			    Bonobo_Canvas_Component__classid))->
	 update(ORBIT_STUB_GetServant(_obj), state, aff, clip_path, flags,
x1,
		y1, x2, y2, ev);

   } else ... /* out of proc */

	ie. you call the stub, which does some macro nonsense to
figure out the vtable on the local object, and the method is invoked
straight with no whacked out argument copying. In fact - bearing in
mind that you can do this is a _very_ useful tool for working out how
CORBA memory management works across process.

> I imagine that it is not possible to pass a pointer to some data
> through Bonobo. You have to marshall your object if you want to do
> give access to it ?

	That is correct; clearly if you are evil, you could pass your
own pointer through as a CORBA_Object if you knew it was in-proc,
since there is no checking of that sort of thing - but it sucks :-)

> Is there a way to count the number of components that actually exist
> right now in Gnome ? In KDE, I can do that by grepping .desktop
> files for service.

	Yes, try:

	oaf-run-query "repo_ids.has('IDL:Bonobo/Unknown:1.0')"

	Or see ${prefix}/share/oaf/

	Each of those files may register 1 or more components, so the
dynamic query is best; clearly with oaf those are Gnome 1.4
components, there are far fewer Gnome 2.0 ones, since they havn't been
ported yet for the most part.

> Apart from Gui components, does Gnome uses true components ?

	We can use Bonobo to access all manner of things,
configuration via our standard property bag interface, the filing
system via the stream / storage interfaces ( + monikers for the vfs )
we also implement a number of non-gui components such as Evolution's
wombat server which implements the calendar / addressbook storage,
or eg. MrProject's project server.

> How well are orbit and bonobo bindings other than C supported ? What
> is available ?

	There are python and perl bindings for ORBit-stable, but in
ORBit2 I've substantialy re-written the ORB, partialy to make it
easier to write language bindings - with generic marshaling, and full
type information available from dlopened type libararies at runtime,
use ORBit2's typelib-dump utility eg. so far we only have guile
bindings for ORBit2 apart from C.

> I have discovered (thank to the ibm article) that writing Corba
> calls in C is pretty tedious but there are sugar wrapper to avoid
> that. Are the sugar wrapper automatically generated or should
> someone write them first ?

	Nope, mostly the wrappers are not client side, but server
side.  They play a big part in interfacing with the un-componentized
bits of Gnome eg. Gtk+ ( sugar for creating controls etc. )
gnome-print etc. etc. Most important is BonoboObject which makes
creating and aggregating Bonobo_Unknowns together much, much easier
than the native CORBA grind which is very hard to understand ( in
comparison with the Gtk+ object system ). So BonoboObject makes using
Bonobo_Unknowns as easy as using Gtk+ objects.

	There are some client side wrappers, but they are fairly few,
some moniker bits, bonobo_get_object eg. some stream read / write
utilities, and the property bag accessors to help manipulate
CORBA_any's.

> Well, that's many questions. :-) I hope you can answer. Thanks in
> advance.

	Certainly :-) I hope it helps, a better understanding of each
other's technologies can only help cross fertilization of ideas, and
future co-operation.

	Regards,

		Michael.

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