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 10:28:08 -0700
Message-ID: <BANLkTik5aK-1nmSD2NUdFdU=7=W89jFaSA@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: Jonas Sicking <jonas@sicking.cc>, David Levin <levin@chromium.org>, Arthur Barstow <art.barstow@nokia.com>, Glenn Maynard <glenn@zewt.org>, 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 Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell <kbr@google.com> wrote:

>
> Thinking about this more, that port could be sent as the data
> attribute of the event instead of the empty string. Then the ports
> attribute on MessageEvent could be safely deprecated.
>
> -Ken
>
>
So a number of different variations have floated around, and I have some
concerns:

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.

2) Rather than having some mix of deprecated attributes on MessageEvent to
support SharedWorkers, I'd rather just change onconnect() to take a distinct
event type that has a non-deprecated ports attribute - I've never been
particularly clear why we're reusing the MessageEvent interface for
SharedWorker connect events anyway. Since Safari and Chrome have supported
SharedWorkers for well over a year now, I would be careful about changing
this interface in a non-backwards-compatible manner - however, if we are not
concerned with backwards compatibility, I would change this ConnectEvent to
just have a port attribute that references a single port rather than a
ports[] attribute that references an array that always contains a single
port.

-atw
Received on Thursday, 9 June 2011 17:28:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT