- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 8 Jun 2011 20:33:12 -0700
- 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 6:26 PM, Kenneth Russell <kbr@google.com> wrote: > On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> 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). > > That's not quite correct; as was pointed out earlier in the thread, > SharedWorkerGlobalScope's onconnect message relies on receiving the > message port with which to communicate to the outside world in the > zeroth element of the ports array. See step 7.7.5 in > http://www.whatwg.org/specs/web-workers/current-work/#shared-workers-and-the-sharedworker-interface > . > > 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. Sounds great to me. / Jonas
Received on Thursday, 9 June 2011 03:34:18 UTC