[cap-talk] OO interoperation via OCap, presentation level issues

[Jed Donnelley]

On 5/8/2008 12:11 PM, Kevin Reid wrote:
> On May 8, 2008, at 13:47, Jed Donnelley wrote:
...
>> Do you (Kevin) consider that "layer on top" to be a reasonable place
>> for standardization that will allow interoperability between OCap
>> languages and OSs?  If not, why not?
> 
> The relevant layer is CapTP (but if one is going to standardize, one  
> should include the layers below it).
> 
> I don't see any serious reasons it shouldn't be usable by other  
> languages, other than that it might require more of an 'E emulation  
> layer' (to support the serialized objects, especially) than a  
> hypothetical designed-for-interop protocol would.
> 
> However, such a generic protocol might well end up being less  
> powerful than CapTP.

I realize we may all have different interests in discussing this
topic of interoperability between OCap languages/OSs.  My interest
is in helping to define the essential and minimal base semantics
for OCap communication.

I don't see how to avoid the usual RPC presentation level issues,
e.g. representations for parameters such as fixed and floating
point numbers and strings.  Do others?  Regardless, I don't
consider these formatting issues essential for the Object-capability
aspect of communication.

What I do believe is essential and minimal is that:

1.  there is a "capability" type parameter that can be communicated,

and

2.  that such a "capability" type parameter is unique in that it
can be the destination (target) of an 'invocation' or call - i.e.
a message communication.  Such a capability enables communications/
requests/invocations.

Beyond the above the issues of presentation level semantics
seem to me to only obscure the essentials of capabilities.

> Note that CapTP needs some more design work to make it future-proof /  
> capable of working robustly between different versions (specifically  
> in definition of what the graph exits are for Data-E serialization,  
> and possibly some versioning / 'do you support this' for future  
> features); the results of that work may well make it more suitable  
> for interop.

I can understand the need for flexibility in such a protocol.

I'd be interested to hear about any need for either more or
less than what I mentioned above (#1 and #2) in the area of
capability representation and semantics in the protocol.

--Jed  http://www.webstart.com/jed/