[omniORB] IDL version problem.

[Nathaniel Smith]

On Mon, Apr 10, 2000 at 08:07:24AM -0700, Carlson, Andy wrote:
> 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.
> 
> In your case, you would leave the old IDL inchanged and suffix your 
> new IDL.
> 
> 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.
> 
> 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.

I'm not an expert on CORBA, but I thought that it already have provision
for this sort of thing in the type id.  For example, if I do
 catior `nameclt bind_new_context test`
then I get
 Type ID: "IDL:omg.org/CosNaming/NamingContext:1.0"
 Profiles:
 1. IIOP 1.0 WyrmWeyr 8088 "8.*.U..y...."
And what is that 1.0 for if not versioning?

Probably someone else on the list knows why this doesn't work out as
nicely as one would hope.

-- Nathaniel