[omniORB] Implementation Repository

[Duncan Grisby]

On Wednesday 15 January, pesco@gmx.de wrote:

> :) This is volunteer one.

Great!

> > 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.
> 
> Can you elaborate that? I've looked at the way MICO does it and they have
> their PERSISTENT POAs register automatically with the ImR if an ORB
> arg to that effect is given. I think that's actually a nice idea. But
> you're right that it should be possible to do it explicitly to support
> any ORB.

I think it's probably wrong to automatically register persistent POA
references in the ImR. An application might have good reason to have a
persistent object reference that should be available whenever the
process is running, and not have the ImR start the process, while
having other objects that do trigger the process.

> But speaking of that, there's the problem of how to create the
> necessary references. The servers must "imbue" their objects' keys
> onto the ImR reference. Is there any way to do that without ORB-specific
> code?

I'm not sure there's any need for the object keys to be given to the
ImR. I think the ImR just needs POA ids and object ids, plus the
references of any currently activated objects.

> Hm, why would the ImR want to autostart particular objects? This can
> be handled by a servant activator or similar in the server, no?

Imagine a particular executable can host two kinds of object. Both are
registered in the ImR. When a request for an object goes to the ImR,
it needs to start the process if it isn't already running, or cause
activation of the object in the process if the process is already
running.

Your IDL looks reasonable for the kind of things needed in the
management interface. I don't have time right now to give outlines of
the other interfaces I envisage, but I'll do it soon.

Cheers,

Duncan.

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