Re: ImR idl proposal

On Wednesday 22 January, kendall bailey wrote:

> Possibly.  It's too early to worry much about that.  I suppose I'm 
> hoping that this become a standard part of the omniORB family.   Still 
> free to work with other orbs, but an official omni* sub-project like 
> omniNotify.  We'll see.

I think it would be good for there to be an omniImR that is part of
the omniORB suite, so I'm happy to go with that name.

> I wasn't too thrilled with the term "program" either.  I couldn't use 
> "adapter" as H&V does.  However, there should be some logical grouping 
> of objects so that a bunch can be migrated all at once.  The ImR could 
> be told that program X is now hosted in process Y rather than Z, and the 
> thousands of objects that once would have auto-started process Z now 
> will start process Y.  The ImR will not store the identity of those 
> thousands of objects.  Rather it knows only the "program" aka "adapter" 
> in H&V lingo.  With a portable ImR there is no need to make all those 
> objects share a POA though.

I haven't completely followed the discussion up to here, so this idea
might be irrelevant, but I've been imagining a scheme where object
identifiers are slash separated strings, like foo/bar/baz/wibble. The
ImR keeps a mapping from partial names to programs (that are running
or it can start). For example, the ImR might know that all names
starting foo/bar are serviced by program A. When a request for
foo/bar/baz/wibble comes in, it kicks A into action, and asks it for
object baz/wibble. Later, the ImR might be reconfigured so that a
single program supports all objects under name foo, meaning that now
the program would be asked for bar/baz/wibble.

I think this kind of scheme would avoid having to come up with names
for the different kinds of entities. You just have simple strings,
part of which are interpreted by the ImR, the other part by the
programs it controls.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --