- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 8 Jun 2011 18:26:39 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- 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: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. -Ken > 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:27:05 UTC