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

[Jed Donnelley]

At 02:54 PM 5/16/2008, Baldur Johannsson wrote:
>I think the essential and minimal base of ocap communication is
>... messages made up of two blocks:
>  one block of capabilities and one block of bits/bytes. Where the
>first cap in capabilities block is destination of the message.

May I ask where you came by this thought?

I ask mostly because I believe it matches my thinking, even going
back to the DCCS in 1975.  Although there:

http://www.webstart.com/jed/papers/DCCS/

the messages are synchronous (more on this later), the messages
consist of blocks of bits/bytes and capabilities just as you
suggest, e.g. these operations (invocations) on a "process" capability:

a. "Read", address; > data;
b. "Write", address, data; > ;
   (read and write the memory of the process)
c. "Take", index; > ; capability
d. "Give", index; capability > ;
   (read and write the c-list of the process)
e. "Find", index, count; capability > result, index;
   (essentially an EQ for capabilities in a process's c-list)
f. "Start"; > ;
g. "Stop"; > ;

where the invoked capability is not explicitly mentioned.  In the
above the parameters before a ";" are the data parameters and
those after are capability parameters.  Those before the ">"
are input and those after the ">" are output (results).

To me this whole discussion nicely illustrates at least
one half of my frustration with this topic:

You (Baldur) and others began to discuss/debate the
sort of message passing (e.g. synchronous vs. asynchronous),
discuss buffering strategies, etc.  I hope we can agree
that these topics are common to any data messaging
mechanism and are not substantively changed when dealing
with capabilities in addition to data.

The other half of my frustration you only briefly
mentioned when you touched on the topic:

>Do you mean type as in designating those particular bits are to be
>treated in that way?

This is what I refer to as the "presentation" level where
one must deal with data representations for "types" of
data such as integers, strings, booleans, and perhaps
more complex types.  In my example DCCS calls above, e.g.:

c. "Take", index; > ; capability

I gloss over this my writing "Take" when such could be
an integer or a string "opcode" and the index would nominally
be a natural number.  One of the nice things about capabilities
that we seem to be able to agree on regarding their semantics
is that they don't need to be separately "type"d (we have no
"integer" vs. "string" capability types - I believe).

I regard both these issues of the synchronous vs.
asynchronous (buffering, etc.) nature of the messaging
and the typing/interpretation of the data as
orthogonal (separate, non essential) to the core
of capability communication and would like to somehow
factor it out.

Unfortunately when considering inter-Vat communication
such as E to Joe-E or E to Caja or even Caja to SAML
assertions ... communication over a network, I don't see
how to "factor" out the synchrony and presentation level
aspects of the communication that are not essential
for what I agree is the simple capability aspects of
the communication.

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.

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?

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