On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell <k...@google.com> wrote: > On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell <k...@google.com> wrote: >>> On Wed, Jun 8, 2011 at 2:39 PM, David Levin <le...@chromium.org> wrote: >>>> >>>> >>>> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell <k...@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