[coyotos-dev] IDL compatibility: the versioning nightmare

Charles Landau clandau at macslab.com
Tue Jul 10 00:44:54 EDT 2007


At 11:02 PM -0400 7/9/07, Jonathan S. Shapiro wrote:
>This illustration
>expresses the heart of the interface versioning problem for capability
>systems.

This was very enlightening.

>If it is intended that versions are backwards compatible, then it
>follows that every A:2 interface must implement all of A:1. If that is
>the case, then it follows that the version construct is not necessary,
>because interface inheritance can already express everything that there
>is to be expressed:
>
>   interface A {
>     void methodOne();
>   };
>   interface A_v2 extends A {
>     void methodTwo();
>   };
>
>and once again the B.doSomething() signature is unambiguous.

I like that. It clearly expresses what is going on.

Even if A:2 does not implement all of A:1, the version construct is 
not necessary:

   interface A {
     void methodOne();
   };
   interface A_v2 {
     void methodTwo();
   };

where A_v2 does not extend A.

>The problem here is that inheritance will progressively lead to a more
>and more fragmented interface tree. So far as I can tell, the only way
>to clean up the mess is to declare that interfaces may be re-collapsed
>at major release boundaries.

In other words, you agree that the "contract" may be broken at major 
release boundaries.

This seems to me to be a reasonable approach, despite:
At 10:44 PM -0400 7/9/07, Jonathan S. Shapiro wrote:
>The answer precisely acknowledges the realities of
>software maintenance: once you go public with an interface, in the real
>world you are stuck with it forever.

Nothing is forever. My MacOS Classic programs no longer run on my Intel Mac.

>Anyway, when MarkM and I last talked this through, we arrived at two
>conclusions:
>
>   1. Everything that can be correctly expressed with versioning
>      can equally well be expressed with inheritance, so explicit
>      versioning mechanism is [not] technically required.

And it doesn't make sense to introduce a mechanism that isn't required.

>   2. Versioning is a nightmare. Forcing it to be expressed through
>      inheritance helps make the nightmare more explicit. I, at least,
>      believe that software nightmares should not be kept in closets.



More information about the coyotos-dev mailing list