[coyotos-dev] IDL code point selection

[Jonathan S. Shapiro]

On Tue, 2007-07-10 at 14:26 -0700, Charles Landau wrote:
> At 12:22 PM -0400 6/19/07, Jonathan S. Shapiro wrote:
> >On Tue, 2007-06-19 at 08:36 -0700, Charles Landau wrote:
> >  > At 10:46 AM -0400 6/19/07, Jonathan S. Shapiro wrote:
> >  > >Cryptographic code points are regrettable because they cannot be
> >>  >efficiently demultiplexed. The problem with any *other* method code
> >>  >synthesis scheme is that central coordination is required to avoid code
> >>  >point collisions.
> >>
> >>  There are many schemes that could avoid collisions in a single chain
> >>  of inheritance. You could have an easily-demultiplexed method index
> >>  in the low bits, and (only for robustness, in case a method code is
> >>  misused) a hash in the high bits.
> >
> >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. Unfortunately, I do
> >not know of any implicit code point assignment strategy *other* than a
> >pure hash on fully-qualified name (or reliably random generation) that
> >does not share this issue.
> 
> How about:
> - the most-significant 8 bits encode the inheritance depth, as now, and
> - The least-significant 24 bits are the method number in alphabetical order
> 
> The alphabetical order will not change unless you add, delete, or 
> rename a method, all of which are incompatible changes, not innocuous 
> edits.

This doesn't seem like a good scheme either.

Concerning depth:

1. There are some rename-like cases where a new hierarchy layer can be
compatibly introduced. This is only possible if hierarchy depth is not
part of the encoding.

2. Even when we reach points where source compatibility is the goal,
many binary things won't get the word. It is therefore desirable to have
as stable a code point scheme as we can.

Concerning alphabetizing:

1. IDL identifiers are Unicode. Since no human-sensible international
sort exists, it isn't clear how to alphabetize them. The best would
probably be lexically ordered by unicode code points.

2. This proposal is not code-assignment stable. See point [2] above.

3. I am not at all clear what you are trying to achieve here. Is there a
flaw in the "cryptographic hash of fully qualified name" scheme that you
can articulate?

shap

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