Re: ActivationContext and shlib servers

[Michael Meeks <michael ximian com>]

On 26 Jan 2001, Maciej Stachowiak wrote:
> 2.) OAF already supports automatic unloading of shlib servers, using
>   oaf_plugin_use and oaf_plugin_unuse. oaf_plugin_unuse was buggy
>   until recently and would reliably crash your app but I have just now
>   committed a fix.

	If you had used the running context code in bonobo it would have
not crashed. People should not be doing manual reference tracking any more
it is a waste of time and is likely to be buggy.

> 3.) Gtk+ 1.2.x does not allow safely unloading and reloading a shared
>   object that defines a GtkType. The reason is that the old GtkType
>   cannot be unregistered, so you can't create a new GtkType with the
>   same name. However, the old GtkType points to memory in the old
>   instance of the shared library rather than the new one, and there is
>   no way to change the existing GtkType. The bottom line is that if
>   your shared library component defines any Gtk classes, you can't
>   safely unload it. If you use only predefined Gtk classes and plain
>   structs for anything extra, though, it should be safe and work
>   properly to unload.

	It should be safe as long as you have no instance init function (
fairly common practice ) and that you build a gtk_type_query into your
whatever_get_type () method.

	We may create a bonobo_shlib_type_uniqe () function to overcome
these issues in a nice way.

> 5.) I think you recently put in a warning about multiple factories in
>   a library into Bonobo, due to misunderstanding how shlib components
>   are supposed to work. I suggest you remove the warning and change
>   the shlib components in question to not use a factory. libmain.c in
>   nautilus/components/tree is again a fine example of how to do it
>   right.

	I don't like the model code. For a start, if this was done with a
generic factory it would be considerably simpler. Secondly it only works
in really simple situations. If the original object creates a sub object
that a reference is held on and then the original object goes out of scope
you get an erroneous unload and a fault.

	Furthermore, I don't particularly like the Bonobo::Unknown going
through a path designed for a GNOME_ObjectFactory which is incompatible -
this might be ok for a remote case where we would get a nice exception on
a mismatched interface method invocation, but in the local case this would
undoubtedly be fatal.

	Of course; if you put some self documenting guards inside
oaf_server_activate_shlib.

	if (pobj->iid) {
		/* Activate the shlib */
		retval = pobj->activate (poa, pobj->iid, local_plugin_info, ev);

		if (ev->_major != CORBA_NO_EXCEPTION)
			retval = CORBA_OBJECT_NIL;


		/* We need a self documenting check here to spew warnings
		   instead of faulting when people do silly things in their
		   oafinfo files

		if CORBA_Object_is_a (retval,
				     "IDL:GNOME/ObjectFactory:1.0", ev)
		 	...

		   NB. Bonobo::Unknowns also come through this path.
		   NB. GNOME_ObjectFactory should be a Bonobo::Unknown in
		   due course.
		*/

		/* Activate the factiories contained in the shlib */
		...
			new_retval =
				GNOME_ObjectFactory_create_object (retval,
								    (char

	It might be more acceptable

	Regards,

		Michael.

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