On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson <atwil...@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