[cap-talk] Petnames versus E-order with ocaps

[Mark Miller]

On Wed, Jan 28, 2009 at 5:02 PM, David Wagner <daw at cs.berkeley.edu> wrote:
> Charles Landau  wrote:
>>Karp, Alan H wrote:
>>> If Bob has a reference to Carol that he calls foo, a
>>> reference to Carol that Bob receives from Alice will also be denoted
>>> foo.
>>
>> Those two references have different properties, so they are different
>> references,

Yes.

>> in other words references to different objects.

No. In E terminology, they are different references denoting the same object.

>> So they should have different petnames.

Not quite.

What hasn't been enough emphasized in this thread is the nature of E's
== (sameness) test. If x and y are both settled references denoting
the same object, then x==y returns true. If x, for example, is
currently unresolved, then x==y currently throws, This is to preserve
the property that if x==y ever returns true, it forever after returns
true; and if it returns false, it forever after returns false. Only
settled references can be used as keys in normal maps (hashtables).

So a petname system built in E would be a 1-to-1 map, implemented by a
pair of normal maps, between names and settled references. If Bob is
not sure x is yet settled, then (ignoring for the moment the
difference between settled and fulfilled), Bob should use a when block
to guard his logic for looking up/ assigning the reference a pet name
until it is resolved:

when (x) -> {
    # ... can safely assume x is fulfilled here ...
    # ... so give/retrieve petname and display ...
} catch ex {
    # ... assume x was broken ...
}

> That sounds on the surface like it may have lousy usability properties.
> Or perhaps what I mean to say is this.  Petnames exist for the purpose of
> helping humans to use the system safely, so any consideration of whether
> these two differences should have the same petname or not ought to take
> into account human factors.

For this reason among others, petname systems should generally not
assign petnames to unresolved promises, and therefore postpone
presenting them through petname user interfaces. By the time Bob's
newly received promise settles into a reference to Carol, all prior
message from Alice must already be ahead[1,2] of any further messages
Bob might send, it is safe to assign it a petname. There is no
conflict here between usability and correctness.



[1] In the current CapTP protocol as implemented in Java on E-on-Java,
we still have the lost-resolution bug
<http://www.erights.org/elib/equality/passing-rules.html#lost-resolution>,
so even if Alice sent a resolved reference, it will arrive at Bob as a
promise, and it will not resolve until after all prior messages from
Alice to Carol have actually been delivered.

[2] In CapTP as implemented by Kevin Reid in E on E-on-CL, he is
either already doing or planning to do something similar in
functionality to the WormholeOp
<http://www.erights.org/elib/distrib/captp/WormholeOp.html> but more
modular. The net effect is similar to the WormholeOp in that VatB
receives VatA, as part of the serialization of the reference to Carol,
the remaining unacknowledged encrypted traffic that VatA still needs
to deliver to VatC. This includes at least all prior messages from
Alice to Carol. So long as this traffic gets delivered to VatC
somehow, VatB can then redeem the reference to Carol that Alice sent,
without demoting it from resolved to unresolved. Since VatB is not
able to deliver this traffic, he is willing to accept this situation.

Kevin, is there anything to read about the simpler alternative to
WormholeOp you've worked out?

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM