[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Bill Frantz]

On 12/5/05, shap at eros-os.org (Jonathan S. Shapiro) wrote:

>Yes. This was precisely my original point, and it explains why we
>describe this hash as the *alleged* type code. It is only
>probabilistically non-colliding, and then only if everyone plays by the
>rules.

The goal of type compatibility is that when some caller uses an object,
"the right things happen(tm)".  This means that a type is both what
method (signatures) the object implements AND what methods the caller
uses (and possibly in what order they are used).  Languages such as Java
get type compatibility through a hierarchical set of Classes and
Interfaces, but this hierarchy introduces unnecessary rigidity.  The
alleged type in Gnosis/KeyKOS allowed an object to say, "Treat me as if
I implement this interface."  In the end that was not sufficient to
convey the nuances of type because it described things at too gross a
level.

For an example, consider Marc Steigler's Pola Car.  This car has a
number of different keys:

(1) The driver's key:  Allows access to the ignition, door locks, and
    trunk
(2) The parking attendant key:  Allows access to the door locks and
    ignition.
(3) The child's key: Allows access to the doors and trunk.
(4) The renter's key:  Allows access to the ignition, door locks, and
    trunk for a limited time.
(5) The mechanic's key:  Allows access to the ignition, door locks, and
    engine.

Note that the privileges of these keys do not fall into a simple
hierarchy.  Attempting to build class hierarchy to describe the
privileges is not going to make the description any easier to
understand.

This car's interfaces can be easily implemented in E because E's notion
of type compatibility is based on the textual method name and the number
of parameters, as presented at run-time.  Using good hashes of the
method names for order codes, as Jonathan has proposed has much the same
effect as a textual comparison of method names, with significantly
higher performance.  Having a conventional order code/method which
returns the order codes for all the implemented methods allows detailed
discovery of the interface methods.

There is still the question of the parameters.  KeyKOS, EROS, and I
assume Coyotos have the characteristic that a caller can pass fewer
capability parameters than the receiver receives.  Un-passed
capabilities are represented as Null capabilities to the receiver. 
There are cases where a Null capability makes sense in a call, and there
are cases where it is an error.  A query operation about each parameter
of a method which returns a list of the methods used on that parameter
along with an indication of whether it may be null will go a long way
toward allowing compatibility to be tested before calling the object.

There is still the issue of method invocation order.  The KeyKOS factory
<http://www.agorics.com/Library/KeyKos/Gnosis/68.html> builder's key
<http://www.agorics.com/Library/KeyKos/Gnosis/71.html> has a call
"install .hole as component" which must be executed before the "complete
factory" call.  I don't have a good idea of how to describe method
ordering requirements for machine processing.

Cheers - Bill

--------------------------------------------------------------
Bill Frantz        | If you ever used the water from your wort
(408)356-8506      | cooler to fill your hot tub, you might be
www.pwpconsult.com | a Californian.