[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Constantine Plotnikov]

Jonathan S. Shapiro wrote:

>When Mark Miller and I looked at this set of issues, we concluded that
>sticking version numbers into interfaces invited (human) mistakes, and
>we adopted the following resolution:
>
>  1. Interfaces are "append only".  You can add new methods and types,
>     but you cannot drop old ones.
>
>  2. When you must make an incompatible change to an interface, you
>     need to change the interface name.
>
>In order to make this rule viable, we assign code points using
>cryptographic hash. This is "deterministic enough" as an assignment
>mechanism, but it avoids any textual ordering dependency within the IDL
>files.
>  
>
It is just a policy or you are inforcing it somehow? Also this rule is 
not so good.  Consider three interfaces:

interface Ret {
    void test1();
    void test2();
}

interface Arg {
    void test1();
    void test2();
}

interface Root {
    Ret method(Arg a);
}

Let's suppose that Root is interface implemented by some service. Ret is 
an object returned from that interface. Arg is an interface supplied by 
caller.

In that case binary compatible evolution would be adding methods to Ret 
and removing methods from Arg. If a new method is added to Arg, a binary 
compatiblity will break (provided that this new method is actually called).

So whether change compatible or not depend on interface usage.

Constantine