- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Wed, 08 Jun 2011 07:30:54 -0400
- To: ext Kenneth Russell <kbr@google.com>, Andrew Wilson <atwilson@google.com>, 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>
- CC: Ian Hickson <ian@hixie.ch>, Travis Leithead <Travis.Leithead@microsoft.com>
Now that the responses on this thread have slowed, I would appreciate if
the participants would please summarize where they think we are on this
issue, e.g. the points of agreement and disagreement, how to move
forward, etc.
Also, coming back to the question in the subject (and I apologize if my
premature subject change caused any confusion or problems), since we
have an open CfC (ends June 9 [1]) to publish a Candidate Recommendation
of Web Messaging, is the Messaging spec going to need to change to
address the issues raised in this thread?
-Art Barstow
[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
On Jun/3/2011 8:47 PM, ext Kenneth Russell wrote:
> 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 Wednesday, 8 June 2011 11:31:30 UTC