W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 9 Jun 2011 14:13:01 -0400
Message-ID: <BANLkTinJdZSBnL8y9Fgw_reD8ejFCa7hQg@mail.gmail.com>
To: Andrew Wilson <atwilson@google.com>
Cc: Kenneth Russell <kbr@google.com>, Jonas Sicking <jonas@sicking.cc>, David Levin <levin@chromium.org>, Arthur Barstow <art.barstow@nokia.com>, Dmitry Lomov <dslomov@google.com>, ben turner <bent.mozilla@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Ian Hickson <ian@hixie.ch>, Travis Leithead <Travis.Leithead@microsoft.com>
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()
> look like. Since cloning a port is a destructive operation, I like the
> that the current postMessage() API requires the developer to explicitly
> a list of ports to clone. If we shift to a paradigm where merely
> a port from the object graph is sufficient to do a destructive clone of
> 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
Received on Thursday, 9 June 2011 18:13:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC