Extending a union by a member - is a mismatch btw. server and client IDL allowed?

[Martin B.]

Our CORBA API currently has an interface like:

module XYZ {
...
enum DataType {
FloatingPointT,
IntegerT
};

// v 1.1
union Value switch (DataType) {
FloatingPointT : double dv;
IntegerT : long iv;
};

interface ... {
Value GetValue(....);
...

We now would like to extend this interface to allow for string values in
addition to the two existing types:

// v 1.2
enum DataType {
FloatingPointT,
IntegerT,
StringT
};

union Value switch (DataType) {
FloatingPointT : double dv;
IntegerT : long iv;
StringT: string;
};

and keep the interface the same otherwise.

Is a client compiled with v1-1.idl supposed to be able to talk to a
server compiled with v1-2.idl -- where the definition of the union (and
the enum) differ but are a pure addition to the existing interface?

Can a client correctly invoke GetValue() as long as this function
doesn't return a unknown datatype?

Is this covered by the CORBA spec at all?

Note: It *does* indeed work when I test it with omniORB 4.1.4 (both
client and server) but that doesn't tell me whether it'll work with all
possible client ORBs!

Thanks for any pointers!

cheers,
Martin

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

[Duncan Grisby]

In article <k0t3fi$r8n$1...@dont-email.me>, Martin B. <0xCDC...@gmx.at> wrote:

[...]

>Is a client compiled with v1-1.idl supposed to be able to talk to a
>server compiled with v1-2.idl -- where the definition of the union (and
>the enum) differ but are a pure addition to the existing interface?
>
>Can a client correctly invoke GetValue() as long as this function
>doesn't return a unknown datatype?
>
>Is this covered by the CORBA spec at all?

The CORBA spec says that it is illegal to have differing IDL on client
and server. However, as long as they are communicating with GIOP, you
will get away with it. The on-the-wire format for unions just sends the
discriminator followed by the value associated with that discriminator.
As long as the receiver gets a discriminator and value it knows, it will
never know that the sender had a different definition.

With an enum discriminator, you must extend it by adding items to the
end of the enum. Enums are sent by numerical value, so if you modify the
order of the enum, the values will be misinterpreted.

You will of course be in real trouble if the receiver gets a union value
with a discriminator it didn't expect. Exactly what will happen depends
on the IDL definitions and how the receiving ORB handles the unexpected
marshalled data. You may get various different exceptions or even crash.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- dun...@grisby.org --
-- http://www.grisby.org --

[Martin B.]

On 21.08.2012 11:29, Duncan Grisby wrote:
> In article <k0t3fi$r8n$1...@dont-email.me>, Martin B. <0xCDC...@gmx.at> wrote:
>
> [...]
>> Is a client compiled with v1-1.idl supposed to be able to talk to a
>> server compiled with v1-2.idl -- where the definition of the union (and
>> the enum) differ but are a pure addition to the existing interface?
>>
>> Can a client correctly invoke GetValue() as long as this function
>> doesn't return a unknown datatype?
>>
>> Is this covered by the CORBA spec at all?
>
> The CORBA spec says that it is illegal to have differing IDL on client
> and server. However, as long as they are communicating with GIOP, you

> will get away with it. ...

Out of curiosity: Where in the CORBA spec is it defined that the server
and client must see exactly the same IDL? Are there exceptions to this rule?

cheers,
Martin