[e-lang] WormholeOp questions

[Kevin Reid]

http://www.erights.org/elib/distrib/captp/WormholeOp.html says:

> When VatA introduces VatB to Carol, she first wormholes the  
> unacknowledged portion of her outgoing VatA-to-VatC VatTP stream  
> through VatB for delivery to VatC. VatB then wormholes it towards  
> VatC before acting on further messages from VatA.

Am I correct that this last ordering guarantee is only for messages  
from VatA which would cause VatB to enqueue more traffic toward VatC?  
I ask because a premise of my CapTP design -- that CapTP messages can  
be implemented as messages delivered to an E object -- depends on not  
having to delay more than can be done synchronously (i.e. enqueue for  
VatB before the end of the turn).

> ... LookupDesc(VatCSearchPath,
>                VatCID,
>                nonce,
>                carolSwissHash,
>                vine) ...

Should this be Far3Desc? There is no LookupDesc documented on the  
main CapTP page.

> So, if VatA and VatB are cooperative, they are both assured that  
> the needed provideFor "from" VatA will be processed by VatC before  
> VatC sees the corresponding acceptFrom from VatB. If either is  
> uncooperative, they cannot cause damage beyond that accounted for  
> by the object-level semantics. Because the data takes redundant  
> paths, neither side will get stuck waiting on the other to timeout.

Am I correct that the reason VatB being uncooperative does no harm is  
that VatB cannot get a reference to Carol until the A->C provideFor  
is delivered, thus not performing the WormholeOp results in  
acceptFrom either failing or succeeding after the older A->C traffic  
has been delivered?

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>