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

John Carlson john.carlson3 at sbcglobal.net
Mon May 19 23:48:06 CDT 2008


>
> If we were to define a standard for capability
> communication - e.g. for now lets pick the simpler
> synchronous communication - and say it consists
> just of data ; capabilities in and > data ; capabilities
> out, that alone won't suffice to allow our
> OCap languages to interoperate - even without worrying
> about the synchrony of the communication primitives.
> It seems to me that one still needs some sort of
> a standard for marshaling and unmarshaling the
> parameters, including any needed "type" identification
> and/or conversions.
>

It seems like marshalling and unmarshalling has been
done many times, with such as things as Web Services, HTTP, MIME, EDI,  
CORBA, RMI, XDR/RPC,DCOM, JSON,
Lisp s-expressions etc. etc.  No need to reinvent the wheel.  You just  
have to find something that everyone can read and write.  My personal  
favorite right now is JSON.

http://en.wikipedia.org/wiki/JSON

> Is there no way to describe the essential and core
> capability concept and to provide for communication
> of capabilities between different systems (language
> or OS) without getting drawn into issues such as the
> synchrony of the communication and the presentation
> of the data parameters?

Well, just looking a the Ethernet standard, here:

http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_EtherType_field

As you may recall, Ethernet was standardized without a type field, so  
it's conceivable to
to provide for communication w/o a type field (as you can read, the  
type was specified in
another standard).

If you want to standardize without specifying a language binding, you  
might look at the X3D
standard.  There's an abstract specification (ISO/IEC 19775) and then  
encodings for XML
and VRML(ISO/IEC 19776)

http://en.wikipedia.org/wiki/X3D




More information about the cap-talk mailing list