[jacorb-developer] TAO_IMR ImR_Client ImplRepo.idl is different between JacORB and TAO

[Timothy Astle]

Hey Phil,

Comments inline below:

On 27/11/2015 2:58 PM, Phil Mesnier wrote:
> Hi Tim,
>
>> On Nov 27, 2015, at 10:31 AM, Timothy Astle <timothy.astle at caris.com> wrote:
>>
>> We were originally generating the stubs ourselves from the ImplRepo.pidl.  This somewhat relates to a prior thread:
>>
>> http://lists.spline.inf.fu-berlin.de/pipermail/jacorb-developer/2013-September/000337.html
>>
>> After seeing that message, I dug around and noticed that I could just use what was in JacORB.  Looking back at that your reply at the time, I'm now wondering if what I had found existed for a while (before your announcement) since you mentioned OCI TAO 2.2a in those notes.  I had assumed that the JacORB 3.3 TAO ImR/NS compatibility announcement was the inclusion of the stubs that I found.  Maybe that wasn't the case?
>>
> Thanks for the link to that message. I think the announcement refers to both the interfaces and the ORB/POA extensions necessary to manage JacORB servers with TAO's ImR. The NS compatibility boiled down to some integration tests, but I don't think the is any interface differences there. Note that we added a section to the programmers guide that refers to the TAO supplied command line utility, tao_imr, for administration of the ImR service.
>
> It is unfortunate that the signature of the list operation was modified in the TAO codebase but not in JacORB, but since it was outside the scope of our objective, we didn't have the resources at the time to validate the rest of the administrative operations so this discontinuity was not detected. Since no one else rose the issue before now, the existence of shared IDL faded from mind. It is too bad back in 2013 we didn't get a better understanding of your objective, perhaps this issue could have been detected sooner, like before anyone was deploying production code.
>
> Were you using the TAO ImR with your JacORB applications prior to migrating to TAO 2.2a?

Yes we were.

>
>> I guess JacORB could have both the 2.0a and 2.2a ImplRepo stubs generated.  Since we're using org.jacorb.tao_imr.ImplementationRepository.Administration directly, we'd just pick the 2.2a ImplRepo stubs "package" (for lack of a better term).  Maybe it's possible to have a class in JacORB in the future that just handles dealing with the TAO ImplRepo interfaces... I have no idea and you'd be the expert there.
>>
>> So I think minimally, having stubs generated for both is probably the safest / easiest approach given what we're seeing.
>>
>> Does that make sense?
>>
>> Tim
> I don't quite follow your idea about a class that handles dealing with the TAO ImplRepo interfaces. Do you mean something similar to the proxy idea I mentioned yesterday, but simpler. Rather that the dii/dsi model, this would serve as the application interface for the TAO ImR control operations. Is that what you mean? We already have something like that for the POA/server integration that is selected by the use_tao_imr property.

Yes, that is what I was floating as an idea, but without the time to 
really think it through.  :)

>
> For the time being, I'd prefer to just fix the current discontinuity in the list operation, and have you fix your code accordingly. The change is small, the compiler will detect all the places the change will be required. Better would be for me to update the whole idl so you have access to some newer operations you may wish to adopt down the road.

Okay, that works for me.  Would it be possible to have a JacORB 3.8 
release soon with that fix?

>
> Adding a second ImplRepo.idl for TAO 2.0a or prior feels like it will take a fair amount of effort. Since you are, AFAIK, the only user of the TAO ImR control operations in the administrative interface, the effort would be wasted as you suggest you are continuing forward with TAO 2.2a. I can't assume the risk to the other known user of JacORB servers + TAO 2.2a ImR unfunded. The effort is too great, and since their objective is met by the current implementation, I can't see them funding a refactor.
>
> Moving forward though, we might want to consider some more changes. For example, I do like the idea of encapsulating the generated stubs in something that is able to deal with future IDL changes. And adhere to principle of only adding new operations, never modifying existing ones. :-)

haha, exactly.  Mistakes do happen.  As always, it's a pleasure having 
these discussions with you.  I appreciate your helpfulness.

Cheers,

Tim

>
> Best regards,
> Phil
>
> --
> Phil Mesnier
> Principal Software Engineer and Partner,   http://www.ociweb.com
> Object Computing, Inc.                     +01.314.579.0066 x225
>
>
>
>
>