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