Re: Comments on the baboon plugin spec

[Elliot Lee <sopwith redhat com>]

On Mon, 14 Sep 1998, Phil Dawes wrote:

> I was just wondering whether it might be better not to have the api
> explicitly deal with shared libraries (i.e. dlopen etc..), but instead
> register the component as a shared library with the implementation
> repository. The client then treats it as a standard corba object (i.e. 
> uses nameservice/trader or stringified-IOR).

In case my opinion isn't clear, it is "screw the IMR".

The IMR is _totally_ undefined. Until the CORBA spec standardizes on an
interface for it (CORBA 3.0 perhaps), it is just a piece of marketing
terminology. 

Some ORB's have implemented a set of services that they call the IMR.
People keep pointing at the TAO design because they think it is good.

The TAO service (which it calls the implementation repository) for
handling activation of servers has these problems IMHO:
	- Requires extensions (ping object, etc.) instead of using
	  existing CORBA spec behaviour.
	- Duplicates the functionality of the naming service
	  (reading the Implementation_Repository interface shows
	   a definite overlap with the CosNaming::BindingContext
	   interface)
	- Doesn't allow explicit control of the life cycle of servers,
	  and no distinction between same-address-space and
	  remote servers (i.e. the servers are only as useful as the
	  clients using them, so the clients should have control over how
	  the servers live and die).
	- Much of the interface works on a per-server basis rather than a
	  per-object basis, which means that the IMR becomes yet another
	  place where you have to muck with the internals of objrefs
	  for forwarding things, etc. (right now there are only ~4
	  routines in ORBit where objref internals are manipulated
	  directly, and it makes adding features like objref structure
	  reuse a lot easier).

LOCATION_FORWARD is a neat trick to use (adding support for this to ORBit
on the client side would be nice), but because the TAO IMR _is_
transparent, you lose a lot of control. So along comes the lifecycle(?)
service to let you specify when servers start up and die and all that. You
wind up running two things (IMR+lifecycle) instead of just doing the
manipulation directly.

</misc thoughts>

> BTW I'm not sure that gnome_plugin is the right word for this
> functionality - what we are implementing here is shared library orbit
> corba servers. Perhaps 'orbit component' might be a better name.

This is a GNOME-specific extension, not a generic ORBit thing. It is
orthagonal to a server being run in the same address space.
ORBit is an ORB, not a component model. "Component" implies a lot more
than just a shared object. etc. etc. etc.

> P.S.  is there a baboon mailing list yet?

This is it.

> P.P.S  Has anybody looked at the corba lifecycle stuff in relation to
> creation and deletion of components. Some sort of reference-counting/
> garbage-collection may be needed.

No, the server process decides when a plugin module needs to die, because
the server process has other purposes in mind (editing a document, etc.) 
and therefore has the control of how long the components stick around.

Plugins are by definition at the whim of the process that uses them, and
while they obviously can be used by other processes, the use of references
to them is as transient as the lifespan of the creating process.

-- Elliot
Progress (n.): The process through which Usenet has evolved from smart
people in front of dumb terminals to dumb people in front of smart
terminals.  -- obs@burnout.demon.co.uk