Re: ImR idl proposal

I thought there would be some value to keeping part of the server identity out 
of the IOR's that the ImR generated.  How would your scheme deal with migration 
of objects from one part of the tree to another?  Say that all foo/bar objects 
need to move to the process B that also hosts abc/xyz objects?  The IORs are 
already published, but now the IOR with foo/bar/baz/wibble really ought to be 
abc/xyz/baz/wibble in order to trigger startup of process B.

This is why I thought a process name could be associated with one or more 
(possibly related in a hierarchy) subsystem names (I've dubbed them 'programs' 
so far).  The IORs would carry only the subsystem names and object names, and 
the ImR would look up the current host process name.

Your scheme could combine the subsytem/object name pair into a single 
structured string as you've described, but not eliminate the need for process 
names.  If that's what you meant, then I can agree with that.  My motivation 
for splitting subsystem names from object names was to avoid imposing any 
structure on the names' formats.  If there is to be hierarchical structure, is 
it advisable to use delimiter characters as you suggest, or should we use a 
structured type similar to the way CosNaming does with NameComponent 
sequences??  I find myself always using the string representation of 
CosNaming::NameComponent sequences anyway, so structured strings are fine with 
me.  In any case, I think the server process should see the whole identifier, 
and not just the trailing portion.  The initial portions may correspond to POA 
names that the ProcessManager can use to traverse the POA hierarchy.


Kendall

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