[omniORB] IDL version problem.

[Carlson, Andy]

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.

Andy
----------------------------------------------------------------------------
-----------
Andy Carlson. AT&T Labs (UK)   	Tel: +44 1527 495258
E-Mail: andycarlson@ipo.att.com	Fax: +44 1527 495229



> -----Original Message-----
> From:	Armin Gerritsen [SMTP:a.a.gerritsen@phys.uu.nl]
> Sent:	Monday, April 10, 2000 2:46 PM
> To:	omniorb-list@uk.research.att.com
> Subject:	[omniORB] IDL version problem.
> 
> Hello,
> 
> We are working on a project that involves a lot of various CORBA
> applications. Now during this project a few changes were made in the IDL.
> These changes make older versions of our applications incompatible with
> newer versions.
> 
> Now because we didn't want to rewrite thos applications (which is also not
> possible since some of the code belongs to other companies which worked or
> used to work with us.). So we wanted to write a sort of proxy:
> 
> myresturn mynewclass::mymeber( mynewparam param)
> {
>  //translate
>  ....
> 
>  myoldreturn myreturn = myoldobject.mymember( myoldparam )
> 
>  //translate back
> 
>  return ...
> }
> 
> This is not reealy a problem, if the objects in the old and new IDL have
> the
> same name (of course). So the compiler will always complain about
> incorrect
> params with iether the new or old function.
> 
> Now I could rename the old IDL and use a different name, but I'm not sure
> this would cause an error when using _narrow().
> 
> Isn't there a better way?
> 
> Best regards,
> 
> Armin Gerritsen