EQ and join

[Mark S. Miller]

>More thoughts (i assumed these went without saying in the first
>message, but i'll be explicit anyway):

You overestimate me.  Please continue to err on the side of explicitness.

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

If/when we switch to Dean's semantics (and perhaps earlier), I would define 
the join-supporting operations to be Miranda operations -- inherited by 
default by all methodical objects, but overridable by them.  Identity is 
pretty universal, and only Miranda-method support for it would enable us to 
switch to Dean's scheme transparently later.

>"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?

Right.  Now the question is, is this a BrandMaker on the join()ing machine, 
or on the machine(s) hosting the object(s) being joined?


         Cheers,
         --MarkM