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

[David-Sarah Hopwood]

Raoul Duke wrote:
>> I think the essential and minimal base of ocap communication is
>> asynchronous messages [...]
> 
> Given that Caps are in the security field, should one worry about the
> asynchronous default leading to buffer resource consumption?

The minimal base of object-cap communication is not asynchronous messaging;
it's just messaging. Specifying asynchronous or synchronous is an
overspecification if we are talking about capability systems in general.

> One can build async on top of sync with more explicit buffering.

That's not the issue. Any serious practical system should provide both
synchronous and asynchronous messaging. It's better for the system itself
to provide both, than for each application to build one from the other in
ways that are slightly incompatible, leading to greater difficulty in
messaging between applications.

The issues are:

a) when asynchronous messaging is used, how do you address the problem
    of potential unbounded buffer consumption, while still obtaining
    reliable forward progress?

b) when synchronous messaging is used, how do you address the problem
    that it's desirable to be able to support partial network transparency,
    but distributed synchronous rendezvous is not implementable?

I think that E has a pretty good solution to b): distinguish between
known-local and maybe-remote references, and don't claim to support
synchronous messaging for the latter. It is still in need of a good
solution to a).

-- 
David-Sarah Hopwood