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

[Baldur Johannsson]

19. may 2008 Jed Donnelley <capability at webstart.com>:
> 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?
>
It came from the realization that the kernel/inter process commsystem
must handle
capabilities in messages. (Checking if sending process has the capabilities
that it wants to put in the message, adding the capabilities to the
reciving process c-list and so on). And it is more complicated to do
that when the capabilities are interspersed through
otherwise opaque data (requires some struct/type system to designate
which bits are caps and which just data) rather than just haveing two
seperate blocks.

> 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/
>
I have read that paper and that is where I "stole" the idea from ;D

> 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.

I choose asynchronous due to the hypothesised fact that in synchronous
communications the process would have two types of wait-for-message.
Open-wait where any other process can sent it a message and closed-wait
where only the called process (or what ever process it delegated the return-cap
to) can send the calling process an message.
Plus the complications of single use return-capabilities. (How do you
handle such stuff
 in distributed context?)
Not to mention the pile-up one malicious process, that never returns,
can cause if it gets
called by an popular server-process. (It is just another form of the
deadlock pileup I gather).
So I choose asynchronous on the same thought as packet switched networks were
build up on.

>
> 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. -snip-

Seems CapIDL* fits this criteria nicely.

> 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.  -snip-
"Opcode"? I would have used the word "method name" or am I misunderstanding
something here?

> 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).

Yes, capabilities are just like opaque protected references.

>
> 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.
>
Well if capability communication is like the act of speaking
then what is said is formed by an spoken language and
when to say it is controled by protocol.

> 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?
>
Well if I continue with my analogy from above: only on the level
on how to speak but not on semantic language level.
But I commend you for trying and I urge you to continue to do so ;-)

Thoughts? Comments? Need for clarification?
-Baldur Jóhannsson

* http://www.coyotos.org/docs/build/capidl.html