- From: Kenneth Russell <kbr@google.com>
- Date: Fri, 3 Jun 2011 17:47:44 -0700
- To: Andrew Wilson <atwilson@google.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Jonas Sicking <jonas@sicking.cc>, 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 4:15 PM, Andrew Wilson <atwilson@google.com> wrote:
>
>
> 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?
Good point; that might inform not deprecating the ports array in
MessageEvent, but leaving it as is.
-Ken
Received on Saturday, 4 June 2011 00:48:15 UTC