Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What differences are allowed between IDL of CORBA server and client?

30 views
Skip to first unread message

Martin B.

unread,
Aug 29, 2012, 3:25:32 AM8/29/12
to
Hi all!

In conjunction with my last question "Extending a union by a member - is
a mismatch btw. server and client IDL allowed?" I have posted a
Stackoverflow Question to try to compile a list of things one can expect
to universally work between different ORBs with different IDL defs:

What differences are allowed between IDL of CORBA server and client?
-> http://stackoverflow.com/q/12121661/321013 <-

Quoting for those that don't want to follow that link:
+ + + +
What I think I know so far is that the CORBA specification as such
doesn't allow any differences between the IDL the server program uses
and the IDL the client program uses.

However, in practice, certain differences are bound to work (pretty)
universally, because the underlying communication mechanism is very
probably GIOP (at least IIOP) and some differences are bound to not be
detectable via IIOP.

What I like to establish is which differences are allowed between the
server and client IDL universally between arbitrary ORBs as long as
GIOP/IIOP is used.

For example: So far I assume it works to:

* Add any type/interface to the server IDL as long as the types the
client IDL knows about aren't touched or any unknown new types sent back
to the client.
* Add a method to an existing interface on the server side -- the client
should be able to continue call objects with this interface, even though
his IDL doesn't list said method. (This seems to be answered with yes here.)
* Add a member to the end of an enum, as long as the client never sees
this new value.
* Add a member to a union, as long as the client never sees this Union
type with the discriminator set to the new value.

My aim is to get to something like a short list of stuff one can do in
an existing IDL to extend "the server" with new stuff without having to
recompile exiting clients with the modified IDL.
+ + + +

Since this is for a concrete project, I may be able to post a list at
least for omniORB<->omniORB and a few tests for TAO as well within the
next time, but I'm obviously interested in what others are saying to this.

cheers,
Martin

--
I'm here to learn, you know.
Just waiting for someone,
to jump from the shadows,
telling me why I'm wrong.
0 new messages