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: Fri, 3 Jun 2011 16:15:33 -0700
Message-ID: <BANLkTink3KxT_QLjG6QOgq_ecCmNSVhYRQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Jonas Sicking <jonas@sicking.cc>, Kenneth Russell <kbr@google.com>, Dmitry Lomov <dslomov@google.com>, David Levin <levin@chromium.org>, 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 Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson <atwilson@google.com> wrote:
> > significant motivation. The stated motivations for breaking this API
> don't
> > seem compelling to me given the existence of backwards-compatible
> > alternatives.
> This proposal is backwards-compatible.  If the argument is an array,
> nothing changes, so postMessage(..., [ports]) is equivalent to
> postMessage(..., {ports: [ports]}).  (The array-only approach can be
> done compatibly, too; the object version is just an alternative to
> that.)  What's backwards-incompatible?

Ah, I missed that piece (to be honest, I haven't been following this
discussion in every detail - I only chimed in because of Jonas' request for
implementation feedback).

> For anyone not looking closely at the IDL while reading this, this
> means deprecating (for whatever value "deprecate" has on the web) the
> ports array in MessageEvent--not the ports parameter to postMessage
> (that's a sequence).

Does this affect the API for the SharedWorker onconnect message as well?
Received on Friday, 3 June 2011 23:16:08 UTC

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