[e-lang] Fwd: Capability Systems and Concurrency

Mark Miller erights at gmail.com
Tue Mar 4 00:22:59 EST 2008


5 of 6


---------- Forwarded message ----------
From: Mark Miller <erights at gmail.com>
Date: Mon, Mar 3, 2008 at 3:34 PM
Subject: Re: Capability Systems and Concurrency
To: Kris Zyp <kzyp at sitepen.com>
Cc: Kevin Reid <kpreid at mac.com>


On Tue, Feb 26, 2008 at 3:57 PM, Kris Zyp <kzyp at sitepen.com> wrote:
 >  > Robust Composition: [...]

>  I have been reading this over the last couple days, very impressive. I had a
 >  question, this may be a elementary, but I wanted to know what is serialized
 >  when a message is passed to another remote vat.

 Hi Kris,

 Kevin Reid (cc'ed) has recently rewritten CapTP
 <http://erights.org/elib/distrib/captp/> to use Data-E
 <http://wiki.erights.org/wiki/Safe_Serialization_Under_Mutual_Suspicion>
 for its serialization. Those two documents probably contain much more
 detail than you're looking for.

 Here, I'll answer in terms of a first approximation in which all
 objects are either pass-by-copy or pass-by-proxy. Pass-by-proxy is the
 default. In order for an object to be pass-by-copy, it must 1) declare
 that it is, 2) be frozen (one level immutable), 3) "selfless", i.e.,
 free of object identity (as are, for example, strings in JavaScript),
 and 4) "transparent", meaning that all of its parts are available in a
 stereotyped way from its public interface, i.e., it doesn't
 encapsulate access to anything else.

 Another term I've toyed with for pass-by-proxy is "stationary", since
 it always resides in the vat in which it was born. However, since vats
 themselves are mobile, this seemed misleading.



 > If there are objects that
 >  are passed as arguments, they are treated as far references in the
 >  serialization, right?

 For pass-by-proxy objects, yes.



 > If the object has public properties, are they
 >  serialized and transferred as well?

 E has no notion of property per se. But you could get this effect by
 passing a pass-by-copy ConstMap object containing public key-value
 associations representing public properties + a key-value association
 whose value is a reference to a pass-by-proxy object containing the
 rest of the behavior you may have in mind.



 > And if so are they treated as immutable
 >  data on the receiving end?

 Yes. And they must have already been immutable on the source end.



 > Or does a message argument serialization consist
 >  purely of primitives and far references?

 In our simplification, purely of pass-by-copy objects and references
 pass-by-proxy objects. However, our intention is that pass-by-copy
 objects can include non-primitives. We don't current support this
 directly. But we support an adequate approximation for now
 (pass-by-construction, aka "pbc", in which the object is asked to
 advise on how to serialize and reconstruct it).



 >  I am very interested in exploring some of the ideas further with my project
 >  Persevere. Persevere is intended to store JavaScript objects on a server, so
 >  browsers/clients can have remote persistence capabilities to access and
 >  manipulate the server provided JavaScript objects. These persisted
 >  JavaScript objects have extensive expressibility that includes most of the
 >  capabilities of transient JavaScripts objects like dynamic
 >  properties/extensible object graphs, and even functions can be persisted. I
 >  think the persistence of JavaScript functions in object graphs would be
 >  particularly interesting to intersect with capability-based security.

 Indeed! One of the issues the Caja project is currently wrestling with
 is what to do about persistence.



 > One
 >  could allow less-trusted sources to store functions, and their capabilities
 >  could be appropriately limited.

 I don't understand this. Can you expand?



 >  I also found the discussions in your thesis on promise pipelines and E-order
 >  to be very fascinating, and would like to utilize that more.

 Thanks. The remaining E-order spec beyond what's in the thesis is at
 <http://www.erights.org/elib/equality/passing-rules.html>. Kevin's
 rewrite of CapTP will be the first to support full E-order, including
 the fix to the lost resolution bug documented at the bottom of that
 page.

 May I forward this correspondence to e-lang
 <http://www.eros-os.org/mailman/listinfo/e-lang> and
 google-caja-discuss
 <http://groups.google.com/group/google-caja-discuss>? Thanks.



 --
 Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM



-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM


More information about the e-lang mailing list