[coyotos-dev] IDL compatibility: the versioning nightmare

[Christopher Nelson]

>
> > Out of curiosity, do you consider the approach of having one dispatch
> > list per version per interface to code heavy and/or to slow?
> >
> > In other words, say you had:
> >
> > interface A:0
> > {
> >    mymethod1();
> > }
> >
> > interface A:1
> > {
> >   mymethod2();
> > }
>
> Umm. No. I said I had:
>
>   interface A_0 {
>      void methodOne();
>   };
>
>   interface A_1 extends A_0 {
>      void methodTwo();
>   };


Yeah, I know.  I think inheritance is ugly. :-D  I should have clarified
that  I was advocating has-a verses is-a.

>
> >   There might also be syntactic sugar allowing you to specify in
> > source that you want the latest version of the interface.  This
> > wouldn't have any effect on binary compatibility with already-compiled
> > apps, though.
>
> Of course it would! You declare that you want the latest version. Some
> method has been dropped. You then pass that cap to one of your services.
> That service needs the old method. Game over.


No. The sugar is source-only. Once the IDL compiler processes the source,
the cap is bound to a single version of the interface. However, I can see
how that is still a problem.  It leads to a combinatorial explosion of
microversioned dispatch tables.

I withdraw the suggestion for a "latest version" feature.  Instead, I would
suggest that versions are part of the first-class type.   If you change the
interface version that a method accepts/returns then you need to create a
new version of your interface, just as you would if you changed the
signature of a method from clearCrypto() to clearCrypto(loggerObject
logger).

-={C}=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/coyotos-dev/attachments/20070710/024ef4d1/attachment.html