[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