[cap-talk] Last Call for ref_send API 1.0

[Tyler Close]

Hi Kevin,

On 4/4/07, Kevin Reid <kpreid at mac.com> wrote:
> Question: What does Eventual#ready do? The documentation and example
> don't make it clear what the difference between its input and its
> output are.

In the ref_send library, unlike in the E language, a promise for an
object is distinct from an eventual reference for an object. This
design is an artifact of Java's static type system. I can't make a
promise for an Integer polymorphic with an Integer. The same is true
for any non-interface. The cast() method converts a promise to an
eventual reference. The ready() operation does the inverse conversion.

To avoid explaining the above, I've hidden the ready() method behind
an overload of the when() method. Is this less confusing for you?

> Question: The documentation does not state explicitly that a resolved
> Promise will (allegedly) from then on return the same value from
> every call to cast(). Is this the case?

A promise created by the defer() method can only be resolved once and
stays in that resolved state forever.

> Comment: E-on-Java provides Ref.makeSwitchablePromise, which has a
> somewhat similar effect to ref_send's Volatile (if I understand it
> correctly). <http://www.erights.org/javadoc/org/erights/e/elib/ref/
> Ref.html#makeSwitchablePromise(java.lang.Object)> This behavior can
> also be built out of the proxy protocols (EProxyResolver/makeProxy).

Interesting. The Volatile interface primarily exists to call out that
clients must be prepared to handle this behavior, since Promise
behavior cannot be guaranteed. I had made the Variable interface
compatible with Volatile to make this behavior available as intended
and agreed behavior, instead of just aberrant behavior. MarkM and
others were uncomfortable with these semantics. It's interesting that
something similar exists in ELib.

> What I am hoping for is that ref_send will have semantics which are
> close enough to E's that a program built on ref_send can
> transparently communicate with a program built on ELib (possibly
> requiring a vat boundary between them).

It seems likely that some level of communication will be possible. How
transparent it will be is the issue. I'm placing a higher priority on:
    - adoption by non-E, but Java programmers
    - compatibility with the HTTP protocol
    - conformance to the Joe-E verifier rules
    - simplicity of implementation so as to facilitate security review
    - amenability to orthogonal persistence

Tyler

-- 
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/firefox/957/