Re: ActivationContext and shlib servers

[Maciej Stachowiak <mjs eazel com>]

Michael Meeks <michael ximian com> writes:

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

No, it's trivial. It's no harder to manage than exe factory reference
tracking.
 
> 
> 	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.

That's not actually safe. It will appear to work but will lead to
segfaults later because parts of the GtkTypeNode private structure
will be pointing into memory in the old location the new shared
library was mapped in, not the new location, and dynamic loading can
map into a new location each time. Trust me, I tried it.

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

The canonical way of using GenericFactory with the object count and
all doesn't solve this problem either AFAIK. The right thing to do is
to up your object count or your plugin use count each time you create
an object implemented by code in your shlib or your executable,
regardless of whether it's created directly by the factory create
function or shlib plugin create function, or otherwise. This does not
seem like a much more onerous burden than your garden variety
refcounting.

However, if you have a better solution for lifecycle management it
would be nice to get that into liboaf so it can also help the (few)
modules that use OAF but not Bonobo.

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

I am not sure what you mean here, and the code (snipped) does not help
me. Can you please give a specific example of a mistake that would
lead to a failure here, so I can understand what you're saying more
clearly? I'm always happy to add more safety checks to OAF.


>               /*
> 		   NB. GNOME_ObjectFactory should be a Bonobo::Unknown in
> 		   due course.
> 		*/

I suspect you're saying this to be provocative but I actually
agree. All interfaces should inherit from Bonobo::Unknown and it is a
grave mistake that the factory interface doesn't, as it makes it less
reusable, and we've added ref and unref to the interface in
anticipation of implementing and using these methods later anyway.

Of course, Bonobo depends on OAF currently for activation, so making
OAF depend on Bonobo would create a circular dependency. Here are a
few possible solutions to this quandry:

* Merge Bonobo and OAF into one module. This is actually probably
  technically the best solution (COM doesn't have a separate
  COMActivation.dll) but is fraught with political issues so I doubt
  it will happen.

* Distribute Bonobo IDL separately from Bonobo and make both bonobo
  and OAF depend on this common module.

* Separate the most basic levels of Bonobo, i.e. the Bonobo::Unknown
  stuff and perhaps the basic moniker framework code into a base
  library which OAF then depends on implementation-wise, and then have
  a higher level which provides standard implementations of common
  interfaces and activation functionality, as well as various standard
  monikers (many of which depend on OAF). If this were done then OAF
  itself could provide the OAF moniker (which would solve my problem
  of OAF only being usable through the C interface and would make the
  life of launguage binding authors much easier).

Do any of these sound like a remotely good idea for GNOME 2? Do you
have any other ideas?

I'd really like to see OAF and Bonobo more tightly integrated for
GNOME 2.

 - Maciej