Re: Interface Versioning

[Dick Porter <dick ximian com>]

On 13 Jul 2001 06:28:39 -0400, Michael Meeks wrote:
> On 12 Jul 2001, Dick Porter wrote:
> > Thats not true! If the signature changes then the application code has
> > to change too, or it wont link.
> 
>         Not true. If [ as you suggest ] we use the 'interface version': 
> the IDL compiler does not mangle this into the stub / skel function names.
> The last time I checked C compilers do not mangle the type and number of
> their arguments into the function name / link time data.[1]

But they do check argument types against the prototype declaration.

> 
>         Consequently you can have:
> 
>         GNOME_Foo (CORBA_Object o, const CORBA char *foo, *ev);
> 
> and then maybe in version 1.1 you do:
> 
>         GNOME_Foo (CORBA_Object o, GNOME_MyStruct *baa, long foo, *ev);

If you ignore the warnings that mixing these two will generate then you
deserve to lose :-)

>   
>         And you will be able to _link_ whichever way you like, with gross
> signature mismatches, and commensurate horrible cockups when you run.
>  
>         If you version in the Interface name [ as you might notice I keep
> hammering on about this ] you get:
>   
>         GNOME_Foo  (CORBA_Object o, const CORBA char *foo, *ev);
> and
>         GNOME_Foo2 (CORBA_Object o, GNOME_MyStruct *baa, long foo, *ev);
>   
>         And it will be impossible to get the thing to link incorrectly.

I must be missing something about C compilers, but I can see no reason
why changing the signature gives you fewer link errors than changing the
identifier (given proper declarations).

>  
>         Of course, you can then activate on IDL:GNOME/Foo2:1.0 and this
> (again) is what I reccommend for interface versioning.
>     
> > >         In conclusion - if you feel you really, have to version your
> > > interfaces - please do it in the human readable, part of the interface
> > > name - and not in the dodgy, unsupported, CORBA 'version'.
> > 
> > ?!
> >   
> > Which is more unreadable? "Open/1.0" vs "Open/1.1" or "Open" vs
> > "OpenEmbracedAndExtended" ?
>   
>         Tell me what version of the interface this method call is using,
> and thus what arguments it should take:
>    
>         GNOME_Foo ()
> 
>         How about this one ?
> 
>         GNOME_Foo2 ()   

If you have prototypes "GNOME_Foo()" and "GNOME_Foo2()" you know no more
than if you have interfaces named "GNOME:Foo/1.0" and "GNOME:Foo/2.0".
You have to look at the IDL in any case.


> 
> 	I still believe that aggregating / appending new features is
> probably the best way to go, since then you don't change the interface,
> and people feel they can atualy trust your interface is not going to
> change and write code against it.
> 
> 	Again the conclusion - please version your interfaces in the human
> readable / IDL compiled portion.

A component knows which version of the interface it implements (it has
to, its a programmer detail.)

An application knows which version of the interface it wants to activate
(again, the programmer wrote it that way.)

For C stubs, the linker will highlight signature mismatches, whether you
version the interface or rename it.  The interesting part though is
dynamically bound interfaces: think of the version as the equivalent of
a shared library soname.  It allows you to extend an interface with a
degree of backwards-compatibility, but also with the option of saying
"oops, major change this time, sorry".

For example, the hypothetical GNOME:Foo/1.1 interface might add an extra
attribute, but thats no reason to suddenly break all the applications
that were happily using GNOME:Foo/1.0. When those apps are updated and
choose to use the new attribute, they can start asking for version 1.1,
but in the meantime you can either a) keep both 1.0 and 1.1 components
around, or (more usefully) b) return 1.1 to apps asking for 1.0. 

> 
> 	Regards,
> 
> 		Michael.

- Dick