On Thu, Jun 9, 2011 at 11:13 AM, Glenn Maynard <gl...@zewt.org> wrote:
> 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.) Great, this makes sense to me too.