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

[Kevin Reid]

Sorry for the long delay since the last report. I tend to not get  
around to writing about what I'm working on.


--- Changes:

- Serialization/reference passing: (r864) <import>.optUncall now  
works for more kinds of non-emaker imports. (r867) Broken references  
are now passed by construction. (r869) Incoming ImportDesc(0) is  
implemented. (r870) Type/Message/ParamDescs now meet the requirements  
of PassByCopy.

- (r868) The basic CapTP connection tests now create a new connection  
for each category of tests, reducing unnecessary state sharing (and  
therefore spurious revisions to keep conceptually independent  
sections in sync).

- (r871-872) I added a pipelined send example, and fixed time-of- 
unserialization bugs in the test revealed by it.

- (r873) Fixed: NewRemotePromiseDesc failed to place the promise in  
the imports table.

- (r876) The Introducer object has been roughly sketched out; it  
isn't hooked up to anything else yet.

- (r874, 877) Translated LocatorUnum and made it an exit so it  
behaves as an unum.

- (r882) The high-level CapTP message representation has been  
revised. Previously, a connection's incoming message interface  
consisted of a "receiver", which accepts E messages corresponding to  
CapTP messages, and a "builder maker", which provides Data-E builders  
to be used for the serialized-object arguments in CapTP messages. I  
have now changed this so the builder maker is not exposed, and the  
object arguments are instead represented as functions (defined by the  
caller) which accept a builder and return the builder's result (i.e.  
they are closures over some Data-E recognizer). This interface allows  
the recipient of a CapTP message to control the timing of  
unserialization, making implementation much simpler (especially for  
the wire protocol serializer).


--- Current:

The next component is the wire protocol (un)serializer. This is what  
turns

   serializer <- GCExport(1, 2)

into [10, 0, 0, 0, 1, 2] and delivers it to some encrypted message  
stream. The basic logic of it is done; I'm currently working on  
designing the 'proper' E/EIO-style replacement for java.io.Data 
{Input,Output}Stream.


--- Design:

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.

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