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

[Tyler Close]

> Assuming that your Acid is the relevant package, rather
> than Droplets, I've
> read through it.

Yes, it is. The 2.0 version is pretty close to the original, but you
should take another look.

http://www.waterken.com/Acid/2.0/

> Very clean, as I've come to expect from
> you.

Thanks.

> 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.

The code in the Acid package does; however, this is only because these
are infrastructure classes. In my application classes (the equivalent
of what E programmers will write) I have yet to use customized
serialization. I suggest that E start out by not providing custom
serialization and wait until there is a demand for it (if there ever
is).

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

I disagree. You can think of BLOBs inside the local database the same
way you think of Vats in the internet. As I pointed out in my first
post, the properties of the two boundaries can be made identical.

> 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.

I vote for not letting clients create serialization streams. Clients
should be ignorant of the existence of serialization. It's just a
trick that Vats use in order to make cross-Vat invocations possible.

Tyler


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com