[coyotos-dev] IDL compatibility

[Charles Landau]

At 6:43 PM -0400 6/19/07, Jonathan S. Shapiro wrote:
>On Tue, 2007-06-19 at 14:30 -0700, Charles Landau wrote:
>>  At 12:22 PM -0400 6/19/07, Jonathan S. Shapiro wrote:
>>  >The current scheme is that the most-significant 8 bits encode the
>>  >inheritance depth, with the "root" value being 1 (to guarantee
>>  >non-collision with RC_OK). The least-significant 24 bits are the method
>>  >number in order of appearance within the interface.
>>  >
>>  >This is not a good scheme. It is vulnerable to many innocuous edits that
>>  >can cause method codes to be inadvertently altered.
>>
>>  Right, that is exactly the problem I encountered in changing the
>>  package name from "eros" to "capros". The exception codes
>>  inadvertently changed.
>
>The case you are describing is a case in which it was *necessary* for
>the exception codes to change. You are imagining that you relocated the
>exception definition from one interface to another. You did not. You
>*deleted* an existing exception definition (which is generally a bad
>thing to do, but not in your unusual circumstances) and inserted a new,
>unrelated exception that has a sufficiently similar name to be causing
>you confusion.
>
>This is a model issue. Your model is reasonable, but it does not
>correspond to the model necessary for IDL to work correctly.

I wish this model were documented somewhere.

>  > >Using inheritance depth was also a mistake. We have already seen cases
>>  >where method names have needed to migrate and/or interfaces have needed
>>  >to be injected into a hierarchy.

Since you say :

>Doing *any* of these after an interface is in
>production use is almost always a fatal mistake. For this reason, CapIDL
>bends over backwards to make this an exceptional pain in the ass to do.

I don't see that using inheritance depth was a mistake.

>  >
>>  How does a hash of the full name solve that problem?
>
>When coupled with the ability to hand-specify the method code, it allows
>relocation in extremis. It solves the problem of interface layer
>injection directly.

The same applies to exception codes. The ability to hand-specify both 
codes would allow me to solve my renaming problem.

>Rename is NOT an innocuous operation!!

>The name defines the
>*identity* of the type or the method.

Perhaps this is why I'm having difficulty accepting the IDL model.
I can change the name of a file without changing its identity, 
because a directory provides a level of indirection.
I can change the name of a procedure without changing its identity, 
if I change all the references to it or introduce a level of 
indirection.
I can change the name of a web domain without changing its identity, 
because the domain name server provides a level of indirection.
I can change my own name without changing my identity.
I'm hard pressed to think of anything for which the name defines the 
identity. To quote Lewis Carroll:

"The name [of the song] really is 'The Aged Aged Man'. ... The song 
really is 'A-sitting on a Gate'"

>The cases where a method can be
>successfully migrated are very very rare.

and

>[renaming etc.] after an interface is in
>production use is almost always a fatal mistake.

But all the above examples can rename with some success.

The computing industry is littered with cases in which renaming 
wasn't anticipated and later had to be retrofitted. That's why 
Macintosh programs have "resources" that provide a level of 
indirection, to permit internationalization.

Obviously I'm too late to the party to influence the IDL model, but I 
can introduce my own level of indirection if that's what I have to do 
to meet my needs.

>Let us test your hypothesis. Since it is just about 25 years later,
>please explain how I would go about getting an exception code added to
>KeyKOS. I'm in a hurry, mind you, so a rapid resolution is essential.

Well, a version of KeyKOS is open source, so you can add it yourself. 
But see the next paragraph:

>  > I think the answer is, if he can't, he assigns the exception code (or
>  > gets IDL to assign it) randomly or cryptographically, and prays (with
>>  high success) that it doesn't conflict.
>
>Empirically this approach has not worked in the real world.

But you are advocating exactly that, assigning all exception codes 
randomly or cryptographically.

Let us test your hypothesis. Suppose Coyotos has gone into production 
and Joe Developer has a body of code. Now you decide you want your 
kernel and core domains to follow the Java naming model, as you've 
said you might. Please explain the migration process. The requirement 
is that at every point in time, Joe's code must continue to run and, 
at Joe's option, compile.

The following year you decide to support programmers in Tajikstan who 
can only understand procedure names in Tajik.