Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]

My understanding is that we have reached a proposal which respecifies
the "ports" argument to postMessage as an array of objects to
transfer, in such a way that we:

 - Maintain 100% backward compatibility
 - Enhance the ability to pass MessagePorts, so that the object graph
can refer to them as well
 - Allow more object types to participate in transfer of ownership in the future

To the best of my knowledge there are no active points of
disagreement. I think we are only waiting for general consensus from
all interested parties that this is the desired step to take.

If it is, I would be happy to draft proposed edits to the associated
specs; there are several, and the edits may be somewhat involved. I'd
also be happy to share the work with Ian or anyone else.

I don't know the various processes for web specs, but the Web
Messaging spec will definitely need to be updated if we decide to move
in this direction.


On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow <> wrote:
> 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]
> On Jun/3/2011 8:47 PM, ext Kenneth Russell wrote:
>> On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson<>  wrote:
>>> On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard<>  wrote:
>>>> On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson<>
>>>>  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 21:24:58 UTC