Re: postMessage is the new wtf

Hi Rick,
here are some clarifications.

There were many (long!) discussions on public-webapps about the new
signature for postMessage:
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0304.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0805.html
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0985.html

window.webkitPostMessage(msg, transferables) does not really exist (it is
an error in the blog post, and I am told the post will be amended). What
exists is window.webkitPostMessage(msg, targetOrigin, transferables).

Regarding second argument to worker.(webkit)postMessage, this is the new
spec for it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
.

The spec mandates 'void postMessage(any message, optional
sequence<Transferable> transfer)'. Transferable includes both MessagePorts
and ArrayBuffers, so in the new spec the transfer argument to postMessage
may be a mix of both types, and a backwards-compat extension to what we had
before (sequence<MessagePort> aka MessagePortArray). Note that message
ports got an additional change in semantics, and can now be mentioned in
the message as well - both
   worker.postMessage({p:port}, [port])
and
   worker.postMessage({p:port, ab:arrayBuffer}, [post, arrayBuffer])
work. Therefore this extension to postMessage semantics is both
backwards-compatible and consistent. On the receiving side, the 'ports'
property of event object will still contain only the message ports from the
transfer list, so that behavior is preserved as well.

I hope this helps,
Thanks,
Dmitry



On Tue, Dec 13, 2011 at 8:24 AM, Rick Waldron <waldron.rick@gmail.com>wrote:

> Following the recent blog post
> http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fastand subsequent Twitter discussion regarding changes to the parameter list
> of:
>
> Worker.prototype.postMessage( message [, transfer ] ) [1]
>
> DedicatedWorkerGlobalScope void postMessage<http://dev.w3.org/html5/workers/#dom-dedicatedworkerglobalscope-postmessage>(any
> message, optional sequence<Transferable> transfer) [2][3]
>
>
> I'm unable to find documentation or discussion that would clarify the
> rationale of over-using and over-loading the "postMessage" Identifier;
> considering the the blog cited above shows this example:
>
> [window|worker].webkitPostMessage(uInt8Array.buffer, [uInt8Array.buffer]);
>
>  which conflicts with:
>
> window.postMessage(message, targetOrigin [, transfer ]) [4][5]
>
> and they both conflict with:
>
> DedicatedWorkerGlobalScope : WorkerGlobalScope ...
>  void postMessage(in any message, in optional MessagePortArray ports); [6]
>
> Currently, passing a second arg to worker.postMessage(), that is not a
> MessagePortArray raises
> "Uncaught TypeError: MessagePortArray argument must contain only
> MessagePorts" in Chrome and "Could not get domain" warning in Firefox.
>
>
> Any reasonable clarification would be greatly appreciated.
>
> Thanks in advance
>
> Rick
>
>
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-worker-interface
>
> [2]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
>
> [3]
> http://dev.w3.org/html5/workers/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
>
> [4]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#web-messaging
>
> [5]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#posting-messages
>
> [6] PREVIOUS SPECIFICATION STATE!!!
> http://www.w3.org/TR/2011/WD-workers-20110208/#dedicated-workers-and-the-dedicatedworkerglobalscope-interface
>