On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson <atwilson@google.com> wrote:
> 1) I'm not completely sure I understand what the new postMessage()
semantics
> look like. Since cloning a port is a destructive operation, I like the
fact
> that the current postMessage() API requires the developer to explicitly
pass
> a list of ports to clone. If we shift to a paradigm where merely
referencing
> a port from the object graph is sufficient to do a destructive clone of
that
> port, I'm concerned that this will lead to very-difficult-to-debug issues
> for developers. So I would say that there is value to still requiring the
> developer to pass a separate "objectsToTransfer" array, even if we
> automagically fixup references to those transferred objects within the
> object graph.
I see the list as a set of objects whose mutating structured clone behavior
should be enabled.
For ArrayBuffer (and most any other object that might be put in here except
ports), it's object transfer. For MessagePort, it's MessagePort's cloning
behavior. MessagePort would have no non-mutating structured clone behavior,
so putting a MessagePort in the object graph without putting it in the
transfer list would be an error, like putting an unclonable object in the
graph; it would throw DATA_CLONE_ERR.
Likewise, putting a MessagePort in the object graph with APIs like History
or Web Storage, which use structured clone but not transfer, would throw
DATA_CLONE_ERR, since the (implicit) transfer set is empty. (In other
words, other APIs would be unaffected and throw the same error they do now.)
--
Glenn Maynard