[E-Lang] Progress & Non-Progress Report

[Tyler Close]

At 11:39 AM 5/15/01 -0700, Mark S. Miller wrote:
>At 01:50 AM Tuesday 5/15/01, Tyler Close wrote:
> >>In the proposed protocol, the issue is dealt with by using the 
> WormholeOp to
> >>reconcile the timelines before the forked reference arrives in the 
> receiving
> >>vat (VAtB).  The WormholeOp page explains some other possible options.
> >
> >So it sounds like the intended E semantics is that receipt of a reference
> >results in a join operation between that reference and all other references
> >in the same Vat that refer to the same target object. You want the comm
> >system to automatically collapse all the incoming timelines into a single
> >timeline. Is the simplified "==" definition the only reason for this?
>
>Actually, I hadn't noticed the need for collapsing back to a single timeline
>until I'd encountered the consequences of giving up on
>http://www.erights.org/elib/distrib/captp/WormholeOp.html#simple-servers .
>This new requirement was a rude surprise, and violated my previous
>understanding of E, as well as the position I was taking in our earlier
>correspondence on partial orders.  Nevertheless, I think we need this
>property.  Does Droplets provide this property or something like it?

Yes, this is actually one property of the reference semantics that has been 
around since the very first trial versions of Droplets. The first versions 
of Droplets just let you manipulate objects in the server's database via 
HTML forms. This is not possible without the "Going Home" property.

> >I've got a potential problem here in supporting this in Droplets. I have to
> >be able to limit the lifespan of different timelines. This means that two
> >references may refer to the same target object, but one of those references
> >may be on a timeline that will be terminated while the other remains valid.
> >A reference does not represent unlimited ability to send messages to the
> >target. A reference represents the ability to send messages within a time
> >window determined by the reference host. So, two references may have the
> >same target, but different time windows.
>
>Does pass<A,B>(x) have the same time window as x?

Yes. The time window is determined by the reference host. The reference 
host always creates the forked reference in the same time window as the 
original reference.

> >This means automatically joining
> >all references to the same target is not a sensible thing to do, the
> >intended time windows would get mixed up.
> >
> >Even if I found a nifty way to support the simpler definition of "==" 
> (These
> >two references refer to the same target object), I'm not sure it would be a
> >good thing to do. If the two references have different time windows, they
> >represent different authority to the target object.
>
>Since E has no such concept, I haven't thought about time windows.  But your
>stance on this certainly seems correct.  I currently have no idea how to
>reconcile these various issues.

Synchronous "==" on far references obtained from different timelines is a 
tall order. I think we should see if there is something less demanding that 
is also satisfactory. I'll think about it.

Tyler