[e-lang] POLA and deserialization

[Kevin Reid]

On Aug 6, 2007, at 18:39, Tony Finch wrote:

> I've been thinking about distributed message passing (in general - not
> specific to E) and how to safely serialize and deserialize  
> messages. In
> particular, I would like to be able to pass objects by copying when  
> that
> makes more sense than passing by remote reference. This is  
> obviously safe
> for "plain old data" types, but more complex types require a  
> constructor
> call.

E makes no distinction between these types.

> However POLA dictates that you must not be able to make me invoke an
> arbitrary constructor just by sending me a message - it could do  
> anything.

"Arbitrary" is the key word here.

This is a matter of capability design: in order for unserializing the  
message to invoke something, it must be possible for the message to  
refer to it.

In E, when you unserialize data from some source, the unserializer  
has a namespace of constructors (or other graph exits). The  
unserialization can only invoke or reference objects present in that  
namespace.

http://www.erights.org/data/serial/jhu-paper/ explains E's approach  
to serialization in detail, including how authority is managed.

Ordinarily, PassByCopy objects' constructors (makers) have no  
authority (DeepFrozen), so they are always available for any incoming  
message.

> I suppose one answer is to make the sender explicitly clone the  
> object. To do so it must have a reference to the remote  
> constructor, according to strict capability rules.

This is also possible. The far reference is serialized by the comm  
system such that it arrives at the recipient as a near reference,  
which may be invoked to construct an object. This would make sense in  
the case where the constructor carries some authority; the sender  
must demonstrate that it has that permission *of the receiving vat*  
in order to make the object.

> However you get better encapsulation if objects are able to  
> determine for themselves whether to pass by reference or by clone -  
> or they might want to migrate leaving behind a proxy, etc.

This is the ordinary circumstance. There may be separate maker  
implementations on both sides; when such a maker is seriaized, it  
becomes an instruction to look up the corresponding object on the  
other side.

> Does E have an answer to this problem?

I recommend you read http://www.erights.org/data/serial/jhu-paper/ .

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