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: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 8 Jun 2011 18:14:35 -0700
Message-ID: <BANLkTi=+xvFKWngknSqdxZ10AuE+hVR3jA@mail.gmail.com>
To: Kenneth Russell <kbr@google.com>
Cc: David Levin <levin@chromium.org>, Arthur Barstow <art.barstow@nokia.com>, Andrew Wilson <atwilson@google.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 4:27 PM, Kenneth Russell <kbr@google.com> wrote:
> On Wed, Jun 8, 2011 at 2:39 PM, David Levin <levin@chromium.org> wrote:
>>
>>
>> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell <kbr@google.com> wrote:
>>>
>>> I prefer continuing to use an array for several reasons: simpler
>>> syntax, better type checking at the Web IDL level, and fewer
>>> ECMAScript-specific semantics.
>>
>> An array makes it harder to do future modifications.
>
> Possibly, but it makes the design of this modification cleaner.
>
>> Also with the array, how does "Enhance the ability to pass MessagePorts, so
>> that the object graph can refer to them as well" work? Specifically,
>> consider an array that contains [arrayBuffer1, port1]. Is port1 something in
>> the object graph or a port to be transfer as before?
>
> In order to maintain backward compatibility, the clone of port1 would
> show up in the "ports" attribute of the MessageEvent on the other
> side. Additionally, during the structured clone of the object graph,
> any references to port1 would be updated to point to the clone of
> port1. (The latter is new behavior, and brings MessagePorts in line
> with the desired transfer-of-ownership semantics.)
>
> All other objects in the array (which, as Ian originally proposed,
> would implement some interface like "Transferable" for better Web IDL
> type checking) would simply indicate objects in the graph to be
> transferred rather than copied.

This all sounds great to me, but I think we should additionally make
the 'ports' attribute on the MessageEvent interface deprecated.

The only use case for it is to support existing code which doesn't
pass ports in the object graph but rather only in the array in the
second argument (i.e. the formerly "ports" argument).

By deprecating it, I mean either:

1. Mark it, using prose, as deprecated in the specification.
2. Remove it from the specification but allow existing implementations
of it to keep it as long as they feel needed to retain compatibility
with existing code.

/ Jonas
Received on Thursday, 9 June 2011 01:15:44 GMT

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