[cap-talk] Horton: who can delay a communicated capability?

[Jed Donnelley]

At 01:25 AM 5/16/2007, Mark S. Miller wrote:

> > Even with the mutually suspicious structure diagramed, however,
> > it isn't Carol (for example as C) that can delay the message from
> > A to B, but rather only the Horton protocol mechanism acting with
> > Carol's identity (beCarol).
>
>The objects whose externally observed behavior Alice and Bob will hold Carol
>responsible for include S2, S3, C, and Carol's Who. Therefore, these 
>(together
>with BeCarol) are all part of Carol. So in this sequential example 
>code, Carol
>(for example, acting as S2) *can* delay the message.

I think this is an important point, so I want to be clear about it.
I would like to know what action object C could do that would delay the
communication of "capability" c from A to B (going from P2 to P3
in the process).  I agree that parts of the Horton infrastructure
S2, S3, and Carol's Who can delay the transfer of this capability,
but I don't see how C can effect such a delay.  If C can indeed delay
the capability transfer, then I have a significant concern.

>Were Carol's Horton objects (S2,S3) properly protected from app-objects (C),
>were C ever invoked, it could delay everything else forever, since the entire
>example system is a single sequential computation. In the example, C can't
>delay the message, but only because it's never given control.

Uh, I think that's my point.  It should never be given control or even
participate in the transfer of the capability from A to B.

>In the actual Horton system, Carol, whether acting as S2 or as C, 
>cannot delay
>the message. Or at least that's my claim.

Personally I'm not as concerned about S2 (as I say, part of the Horton
"infrastructure" - though it may be important to look inside for
some purposes), but I'm quite concerned about C.  I'm comforted to hear
you say that C can't delay the message in the 'actual Horton system',
though I don't even see it in the E code in the paper.  As I mentioned
I think there are still some things I need to learn about that code,
some of which I think would be helped if I had a running version
that I could instrument.

> > A in step (1), executes b.foo(c),
> > "thinking" it is sending the message "foo" to receiver
> > B with a reference to object C as an argument.
>
>As per your suggestions, this was fixed right before posting to cap-talk. It
>now reads:
>
>Here, we examine a scenario in which sending
>object A executes b.foo(c), intending to send
>the message "foo" to receiver B with a reference to
>object C as an argument (Figure 1, (01)).

Ah - good.  Sorry I missed that MarkM.  This "event" is happening pretty
quickly...  I'm not sure how I picked up the older version
(maybe when I looked back at "t" for Charlie), but I'll try
to be more careful about that.

Even with the above I think the topic of whether or not
the sending/invoking object is aware of the responsibility
transformation of the sent object is an important one.
It's the distinction between whether A expects B to
'receive' P2 (Alice's responsibility) or P3 (Bob's
responsibility).

>Yes, I'm flying out early tomorrow morning, and will be flying back Monday...
>...intermittent email ... top priority Tuesday ...

Have a good trip MarkM!

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