Re: Few questions about Bonobo

[murrayc t-online de (Murray Cumming)]

On Fri, 2001-09-28 at 03:14, Michael Meeks wrote:
> 
> 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 ],

This seems confusing. I thought that the component was the server, used
by the client. If the frame is using the component then isn't ii
confusing to call the frame a server? Yes, I know that everything tends
to be a server and a client at the same time, but in this action it
seems to be the client.

 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 ?

I think that he's asking how you define the component to be in-process
or out-of-process. I seem to remember that with COM it's a matter of the
registration of the component.

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