[omniORB] Implementation Repository

[Duncan Grisby]

On Tuesday 7 January, Thomas Lockhart wrote:

> Hmm. I'd like to try this, but would like the discussion to be on-list 
> to see if we can get one or two other folks volunteering before we crank 
> up for the work. OK?

Yes, I think the discussions should be on the list.

A quick summary of my thoughts on the matter:

The ImR should only use standard features that can be implemented with
all ORBs. All the other ImR implementations I've seen involve magic
behaviour by POAs and ORBs, in response to being started by the ImR. I
think that's a bad thing since it requires ORB changes, and because it
makes it much harder (impossible, usually) to use more than one ORB
implementation.

The way I see it working is to have a set of ImR interfaces
implemented in the ImR itself, and a control interface that is
implemented by servers that are started by the ImR. When the ImR
starts a server, it passes a reference to itself via an -ORBInitRef
command line argument. The newly started server can then call back to
the ImR passing it the control object. The control object would have
operations to start and stop particular objects, and exit the process.

If all of this is well defined, it should be easy to use it with any
ORB. There's plenty of scope for support libraries, too, so
applications don't have to deal with it all directly.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --