[coyotos-dev] IDL compatibility

[Jonathan S. Shapiro]

On Mon, 2007-07-09 at 14:07 -0700, Charles Landau wrote:
> While we're on the subject of IDL, and now that MarkM is back, I'd 
> like to reopen this discussion by posing some questions.

I have already answered Charlie's questions, but let me do so again.

> 1. Is it possible to have more than one name for the same method?

Yes. There are three ways to do this:

  A. The bad way: add a second declaration with a matching signature
     and assign it the same method code point as the first one.

     This should not be allowed to work. Future versions of CapIDL
     will enforce the "no overlapping code points" rule.

  B. The less bad way: add a second declaration with a matching
     signature, and treat the two method code points identically in
     the server.

  C. The good way: define a new version of the interface, do whatever
     the heck you want in the new interface, and leave the old version
     of the interface unmolested.

The *very important* missing piece in CapIDL is that it does not make
provision for interface versioning. This is because neither I, nor
MarkM, nor anybody else in this business seems to have the foggiest idea
how to do that sensibly. The problem is that interface versions entail
both upward and downward compatibility constraints.


> It is desireable to have more than one name, for several reasons.
> a. You come up with better names. For example, you decide 
> "CreateWidget" is preferable to "MakeWidget". You want to add the new 
> name, but retain the old for compatibility.

This is not a good justification for renaming a method, because it is
not a good justification for breaking a source-level contract. It may or
may not be a good justification for adding a library routine.

Test: if someone came up with a better name for printf(), would it be
justified to rename it?

> b. Users come up with better names. For example, a Francophone 
> prefers to use ""CreerWidget".

This is similarly not a good justification for renaming a method,
because it is not a good justification for breaking a source-level
contract.

Test: if someone came up with a better name for printf(), would it be
justified to rename it?

> c. You rename something ("eros" to "capros", just to take a random 
> example). You want to add the new name, but retain the old for 
> compatibility.

This case, I think, reveals Charlie's real focus. I'm pretty sure this
is a bad idea, but since Charlie hasn't articulated what his higher
level objective actually is, it is difficult to respond sensibly.

What Charlie is proposing here is a form of intentional method name
collision at the binary level. The "theory of operation" of IDL is that
this sort of collision is precisely what you are trying to *avoid*.
Let's explore what the benefit or cost of intentional collision might
be:

  1. Binary compatibility, but only for those methods that match,
     and not for interface type ids.

     This seems unlikely to be useful.

  2. To the extent that binary compatibility exists, conflation of
     designs.

     Once the code points are locked together, they can never be
     unlocked. If *either* party revises the interface, the other
     is screwed.

So now let's examine the benefit:

  3. One less case in a switch statement that is dispatching on
     cryptographically assigned identifiers.

     On average, this will save exactly one branch instruction
     in the switch dispatch sieve. It isn't worth it.

If the hidden goal is to support capros->coyotos migration, then a sed
script or a compatibility library are probably better approaches.

> 2. If it's not possible, how can I solve the issues above?

Since Charlie hasn't articulated the problem he is actually trying to
solve, I suggest that we cannot yet answer this question.

> An answer that says "you have to get it right the first time and 
> never change it" ignores the realities of software maintenance.

No, it does not. 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.

However, you are making a valid point as well: there is an interface
versioning issue, and it is real, and there is no known good design for
dealing with such issues other than introducing new interfaces having
new names. I will take this up in my next note by responding to one of
Charlie's other questions to illustrate why his assumptions about adding
names are incorrect.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC