EQ and join

[by way of "Mark S. Miller" <markm@caplet.com>]

On Wed, 8 Sep 1999, Mark S. Miller wrote:
 > At 05:57 PM 9/7/99 , Ka-Ping Yee wrote:
 > >It occurred to me while driving to the dentist today that it
 > >might be possible to retain the flexibility that Dean described
 > >while still making it easy to do "join" in E.  Could the "join"
 > >function simply implement Dean's rendezvous-with-a-sealed-box
 > >protocol, hiding the tedium from the casual E user?
 >
 > I like that.

Hooray!  I contributed a useful security-related idea.  :) :)

 > May I forward this correspondence to the e-lang list?

Certainly.

More thoughts (i assumed these went without saying in the first
message, but i'll be explicit anyway): Dean's protocol requires
that the object to be joined must respond to messages to store
and retrieve the sealed entity.  So, we retain the ability to
provide join on some objects and not on others.  When the object
does not provide the necessary interface, "join" would cause an
exception, which is fine.  (I suppose it would be good to choose
nice names for the messages such that, when the exception is
"no such message", it's still obvious why the join failed.)

"join"'s other dependency is on the BrandMaker, since i think it
would have to make a new [sealer, unsealer] pair each time it
was invoked, right?


-- ?!ng