[coyotos-dev] GetTypes() and IDL

[Constantine Plotnikov]

Jonathan S. Shapiro wrote:

>>>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?
>>    
>>
>
>The most general one: if you and I are compiled to different versions of
>an interface, then getType() may not be useful. Worse, if I have an
>interface that expects a capability of type T, you can *hand* me an
>interface of type T, but because of changes in the interface they may
>not be the same T.
>  
>
I have thought about the problem a bit. And I think that it is caused by 
misapplication of the abstraction. Coyotos is dynamically-typed 
object-based system, not a statically-typed class-based system.  When it 
is discussed it in terms of statically-typed class-based systems, the 
problems naturally occur.

The statement "the capability A implements the interface X" means "the 
capability A declares that it will respond to messages declared in 
interface X at this moment of the time". The type can actually change in 
case forwarding proxy. If reference to one capability is replaced with 
another, the type of proxy may change.

The statement "the argument of message implements the interface X" means 
"the receiver of the message expects that the received capability 
supports all messages declared in the interface X".

The statement "the method return capability that implements interface X" 
means "the caller might expect that  returned capability will respond to 
methods declared in the interface X".

I would like if Mark Miller would jump in and describe E approach or 
provide a reference to it, because E is also object based system and 
they try to support interfaces too. And E also supports transparent 
forwarder pattern like Coyotos, so type can be also changed in the 
runtime. E case might be simpler because of more control over runtime 
and much cheaper calls.

A capability responds to messages and interface describes a set of 
supported messages.  Currently, if two interface "InputStream" and 
"ByteStream" are independently declared that both have the method 
"close" that returns nothing and the "read" that return array of bytes, 
these interfaces are completely identical from Coyotos point of view. 
Any distinction between them will be completely artificial.

Therefore in context of Coyotos, if we stay consistent with the IPC 
system, the equality rules should be the following:
1. Two messages are the equal if they have the same transfer representation.
2. Two message definitions are equal if sets of possible messages 
conforming to them are the equal.
3. Two interface definitions are equal if sets of message definitions 
are the same.

This is where the fun starts. The place where we can play is the first 
statement, because all next ones are implied by the fact that the 
Coyotos object system is object-based and dynamically-typed (and the 
type of object can change for more fun).

AFAIR a message in Coyotos is identified by hash of the method name. 
Other information might be included into the hash to make different 
messages distinct. For example, it is possible include something from 
the following:

1.  Names of arguments and names of structure fields. In that case if 
different names have been used for arguments or fields in structure 
definition, the messages will be different.

2. Types of arguments and structure fields. If this is not included than 
methods test(a:uint32, b:uint64) and test(a:uint64, b:uint32) will in 
practice describe the same set of messages.

3. A qualified name of interface that contains the method. In that case 
wombat::InputStream.read() and acme::ByteStream.read() will be different 
messages. If this is selected, the name of struct type names might also 
participate in the hash. It is another question whether it is useful or not.

4. A set of methods that should be implemented by received or returned 
capability (subject to a great fun with dependency cycles, however the 
problem might be resolvable).  If this information is not included into 
method hash, the type of received or returned capability is a human and 
tool consumable annotation that does not play part in into message 
comparison. Actually I think that this information should not be 
included into the hash. Because what is returned form method should 
support at least these method in future, but what is received should 
support at most the specified methods for binary compatibility. Because 
it is an inequality constraint, than it should be ignored in the 
equivalence. A possible workaround for it would be to support all legacy 
interfaces on the same capability too.

Adding something or removing something will obviously change all derived 
equivalence classes.

Considering all above, because Coyotos uses structural equality of types 
rather than name equality, both getTypeCode() and getTypeName() in 
present form are completely useless for Coyotos without interface 
definition retrieving function. And they should be introduced only after 
interface definition retrieving functionality is introduced. Interface 
name currently is local to interface definition and just provides name 
to a set of messages. They might only useful if a process have single 
compiled interface description file that is always returned on get 
interface request and getTypeCode() and getTypeName() are used to lookup 
an actual interface in the set.

There might be other getTypeCode() method that returns a hash of 
capability interface with respect to the selected equivalence class 
(i.e. the same hash is returned for interface definitions that are in 
the same equivalence class). This method might be used for avoiding 
repeated retrieving of the full interface definition in the scripting 
languages.

BTW isOfType() method should receive a list of message definitions/codes 
rather than a type code. The method should return true if all requested 
methods are available.

>Let's also defer the question of IDL encoding. For the present
>conversation, it doesn't matter if we use XML, binary, or simply use IDL
>source directly.
>
>So now look at the IDL-level problem. Suppose I have an interface of the
>form:
>
>  interface I {
>    someMethod(int x, I2 someCap);
>  };
>
>where I2 is another interface. If I ask for the IDL representation of I,
>how much should be returned?
>
>  
>
The following information should be returned:

* Information that participates in the equivalence type definition in 
some canonical encoding.

* Human and tool consumable information that help to construct message. 
This is practically an encoded AST of IDL files with resolved references 
and compiler generated information like message codes.

It could be two separate requests.  I suggest returning to it after 
discusion if about general approach specified above.

>Another way to ask this question is: how should interface version
>numbers be handled? When should the version be updated, and how should
>correct version maintenance be checked? What is sensible behavior when
>the expected version and the received version do not agree?
>
>  
>
I think that some of these questions is invalidated by considerations 
above or they at least should be reformulated. If interface is 
considered to be just a set of operation, most questions about versions 
do not make sense.

Constantine


PS: Note that this situation is similar to situation with web services. 
It is also dynamically-typed system. The interface is a collection of 
operations. The operation has input message, output message and fault 
messages. In WSDL 1.1 there has been even separate element that has 
defined a message as separate entity from operation, in WSDL 2.0 
operation refers directly to XML element definition in the XSD schema.

In web services, there is no a web service request that returns as WSDL. 
However by convention, WSDL is available at location 
"<url-of-web-service>?wsdl" for most of web services. Returned WSDL is 
usually self-contained. It contains all XML element definitions and 
interface definitions. However WSDL do not deal with references to other 
web services, so there is no problem with specifying the interface.

PPS: I need to think about implication of all of this on shell 
languages. I will possibly write another message later.