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: Andrew Wilson <atwilson@google.com>
Date: Thu, 9 Jun 2011 11:15:51 -0700
Message-ID: <BANLkTikLaRL0jpftkQsy-ipAy68K1qiosw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
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 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.
Received on Thursday, 9 June 2011 18:16:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:32 UTC