[E-Lang] Rights Amplification: The Next Layer Up

[Mark S. Miller]

At 08:12 AM 9/6/00 , Tyler Close wrote:
>There's another way of looking at this problem. The other way leads to
>a better solution. You can see it in action by playing with the
>Droplets environment. (Hmmm... a persistent capability system, wonder
>if I'd find any clues there?)

Assuming that your Acid is the relevant package, rather than Droplets, I've 
read through it.  Very clean, as I've come to expect from you.  I think I 
now get it well enough to respond to the rest of this, or at least ask 
questions.


>In tl-E, you've only got one kind of local settled reference, the Java
>primitive reference. When thinking about serialization, this forces
>you to try to solve issues by mucking around with the object. That the
>Java APIs also muck around with the object doesn't help your
>intuition.

Interesting point.

(For those who don't recall, "tl-E" means "time-local E", in that the 
objects don't survive any longer than their OS process does.  A persistent E 
is not time-local.  A distributed E is not space local.  The current is E 
distributed & time-local.)


>The better way to handle serialization issues is to muck around with
>the references. The references are already something that the TCB is
>expected to muck around with so we're not spreading the muck. You will
>also be forced to muck around here a bit in order to implement
>transparent object faulting.
>
>I'll start with the conclusion and then work back from there. You can
>stop reading once you get it.
>
>The conclusion: "All implementation level objects are pass-by-copy".
>This means that the serialization subsystem, whether comm or local,
>should serialize any Java reference that it happens upon. Happily,
>this is also what Java Serialization has done ever since it's first
>version.

I think there are several separable issues here.

1) At the Java level, should the comm system distinguish 
pass-by-serialization vs pass-by-proxy by a property of the object (such as 
a marker interface), or by a property of the reference (a direct java 
reference vs a BLOBReference).  This would make the comm system simpler, at 
the price of possibly making everything else more complicated.  Your 
argument that we need to pay this complexity in order to get Acid-like 
persistence is plausible.

2) Should objects that are being serialized be able to customize their 
serialized form?  Your own code has some readObject() and writeObject() 
methods here and there to customize serialization.

3) If we want to enable the E programmer to occasionally customize an 
object's serialization, some customizations will be serialization-subsystem 
specific.

4) Should all objects serialized across the comm system by copy be 
transparent?  By transparent, we mean that it doesn't encapsulate any state. 
Generally the answer is yes, but with one glaring exception -- SturdyRefs.  
A SturdyRef should serialize its state across a comm system that it believes 
not to be confined -- presumably the same comm system that made the 
SturdyRef.  However, it must not reveal these bits to its clients, since 
they may be confined 
http://www.erights.org/elib/capability/dist-confine.html .  If such clients 
can create serialization streams, these must lack the ability to demonstrate 
some authorization that the comm system can.

More later.


         Cheers,
         --MarkM