[omniORB] Implementation Repository

[baileyk@schneider.com]

>On Wednesday 15 January, duncan@grisby.org wrote:
>>On Wednesday 15 January, baileyk@schneider.com wrote:

>> I'm also interested.  I'd like to know how the indirect binding is going
to
>> be handled if the POA itself does not interact with the ImR when it
>> generates an object reference.

> Can you explain what you mean by "indirect binding"?  Do you mean
> creating an object reference that has the ImR details in it, rather
> than details for the current process?  If so, that just requires one
> explicit call to the ImR.

Yes.  I'm using the terminology as defined in Henning&Vinoski chapter 14.

An ImR would allow some persistent POAs to use transient port numbers.  At
least that's my experience with Orbix 2000.  The IOR points to the ImR host
and port.  You're saying application code would first ask a persistent POA
to generate an object reference, and then explicity pass that to the ImR in
order to get the indirect reference?  That sounds OK, I guess.  The ImR
might end up being portable, but server code would not.  No other ORB's ImR
would require such explicit generation of indirect references.

Also in H&V section 14.4.5, it's described that an ImR would need to know
how to decode the object key of a reference in order to find the POA name.
If this can't be done, then does the ImR need to keep a persistent store
mapping indirect references to the direct references?  I see a potential
scalability problem if so.  Is there a real need to use a single ImR with
multiple ORB product?

Once an explicit approach is done, wouldn't it be advisable to add code to
the POA to use the ImR interface to automatically generate the indirect
reference?  What I imagine is a configuration parameter that tells the POA
if/how to contact the ImR.  If so directed the POA would check with the ImR
to see if the POA name is already registered as using indirect binding and
if so get/construct the indirect reference directly.

>> Would it be a good idea to prototype the ImR in Python first?

> I think Python would be a good language to do the full thing, not just
> a prototype. It has the advantage that someone else has already dealt
> with a lot of the platform differences that makes starting and
> stopping processes a pain.

True.  However, do a majority of omniORB users (at least those interested
in an ImR) want to have Python and omniORBpy installed *and* deployed into
their production environment?  Sounds good to me, but I wasn't sure the
consensus would be for a Python implementation.

Thanks,
Kendall