[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Constantine Plotnikov]

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
>IDL specification.
>
>  
>
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
>deal with.
>
>  
>
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):

http://www.w3.org/TR/ws-desc-reqs/

Associated usage scenarios would also be helpful. An example of possible 
format:

http://www.w3.org/TR/ws-desc-usecases/

>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.

Constantine