[coyotos-dev] Some comments on Coyotos Microkernel Specification
cap at isg.axmor.com
Fri Dec 9 03:58:56 EST 2005
Jonathan S. Shapiro wrote:
>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.
getAllTypeNames() does not provide any additional information beyond of
what is already abtainable. It is just a shortcut that is implementable
by examining interface definition. It is supposed to return exact
interface type name as getTypeName() and names of all types that are
extended by that interface. For example for coyotos.process instance the
method will return an sequence that consists of coyotos.process, and
coyotos.cap. In the previous example I have assumed that
com.adobe.PDFPrinter interface type extends coyotos.directory.TextPrinter.
>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
It is useful for exploring, scripting, and cofiguration. These
activities involve human more closely and human understandable name
would help much here.
>The problem with *that* is that there is an unsolved research problem
>involved: how to deal with version dependencies.
There quite a lot of possible problems with version dependencies. Could
you please clarify which one you are concerned with?
>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
Ok. Please writer a short list of requirement of what right thing should
be. If requirement are high-level, it will help. Because in that case
there will be more ways to implement them. A good example of possible
format is (a simple list would also work):
Associated usage scenarios would also be helpful. An example of possible
>If someone wanted to sit down and organize a coherent proposal for how
>to deal with IDL interface versions, that would be *really helpful.*
I can try doing it. But I need requirements first.
More information about the coyotos-dev