[coyotos-dev] Some comments on Coyotos Microkernel Specification

Jonathan S. Shapiro shap at eros-os.org
Thu Dec 8 12:56:59 EST 2005


OnSo I suggest a simple compromize solution:
> - leave getTypeCode() method as it is and document it that is based on 
> hash and therefore loosy. It still can be useful for a quick typecheck 
> on input parameters.
> - add  getTypeName() method that return alleged type name as string.
> - add  getAllTypeNames() method that return a sequence of strings that 
> includes type name and and names of all types that are implemetned by 
> this interface. This method is required to determine if some object on 
> the directory is a "coyotos.directory.TextPrinter:1.1" even if its type 
> is something like "com.adobe.PDFPrinter:1.1".
> 
> If this is acceptable, then the issue is closed from my point of view.

getAllTypeNames() is absolutely not okay in general -- the object should
not be disclosing other interfaces in the general case. The right
protocol is to prove that you are entitled to the interface by
demonstrating that you already hold a capability.

The problem here is that the interface string name doesn't actually tell
you anything useful. It's helpful for debugging, but it doesn't tell you
the protocol. What you really want here is something equivalent to the
IDL specification.

The problem with *that* is that there is an unsolved research problem
involved: how to deal with version dependencies.

It's not that I object to strings. It's that they aren't as useful as
you think and the *right* thing is more complicated than I know how to
deal with.

If someone wanted to sit down and organize a coherent proposal for how
to deal with IDL interface versions, that would be *really helpful.*


shap



More information about the coyotos-dev mailing list