[omniORB] IDL version problem.

[Armin Gerritsen]

> Armin,
>
> The approach we use is to enclose all IDL definitions in a module
> and apply a version suffix (e.g. _V1_0) to the module name.

Thanks!

> In your case, you would leave the old IDL inchanged and suffix your
> new IDL.

This would however require a change in our current (new) IDL and therefore
also source-code.
It would be a fix, but our partners might not like it. But of course if
there is no othetr way, they have no choice. :-)

> This approach means that to CORBA apps, the two interface versions
> (and any associated typedefs, structs etc) are completely separate.
> The good thing about that is that you can build translation proxies or
> build servers which support both versions of the interface. It also means
> that there are no restrictions on what changes you can make to your
> IDL between versions. The bad thing about it is that the CORBA system
> is unaware of any relationship between the two versions, so there is no
> backwards compatability 'for free'. You also need to figure out how
> clients are going to find servers with the correct interface version - one
> possibility is to use the Naming service and add versioning suffixes to
> the Naming Service names too.

We have that fixed because all the applications use IOR-strings and no
nameing services at all.

> The other oft-quoted approach is to make the new version of the interface
> a subclass of the old one. This gives you backwards compatability but
> prevents you making any changes to existing method signatures,
> structs etc.

Mmm, this would also require a change in IDL. So from our point of
prospective is not more or less work. So the first method would be the least
worse.

Thanks,

Armin