>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