[e-lang] CapTP in E progress report #5

[David Hopwood]

Mark Miller wrote:
> On 8/13/07, Kevin Reid <kpreid at mac.com> wrote:
>> An issue that had been raised is: what does a passed disconnected ref
>> arrive as?
>>
>> I find that under the mechanisms my ELib provides, passing a
>> disconnected ref necessarily results in an unconnected ref, because
>> the proxy->disconnected transition discards the proxy handler (so
>> Ref.optSealedDispatch can't be used on it to retrieve the original
>> identity); furthermore, this is the simplest thing for an uncaller to
>> implement (testing with Ref.isBroken or similar).
>>
>> I think this is not too unreasonable behavior. For one thing,
>> attempting to preserve the unconnected ref's identity would, given
>> non-transitive network failures, result in a disconnected ref
>> possibly arriving as a far (non-broken) ref.
> 
> If our only choices are that a disconnected ref 1) arrives unconnected
> vs 2) that it might arrive non-broken, then I'd agree that #1 is
> preferable to #2. I haven't thought about it much, but my immediate
> reaction is that #2 would not be acceptable.

What are the precise meanings of "unconnected" and "disconnected" here?

Alternatively, where should I have looked to answer this question?

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>