Re: postMessage is the new wtf

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

>  I'm unable to find documentation or discussion that would clarify the
> rationale of over-using and over-loading the "postMessage" Identifier;
>

It's not strange that there are differences between methods on completely
different objects; it's not something that needs special explanation.
Using different names for very similar operations would be inconsistent, as
these do the same thing: post a message.  The primary difference is an
added security mechanism for the cross-document messaging that
window.postMessage can perform.

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.
>

This is a very new feature, and isn't yet available in production
browsers.  Try http://tools.google.com/dlpage/chromesxs, which does have
this.  (As that's a development build, it may not yet be working
completely, of course.)



On Tue, Dec 13, 2011 at 2:11 PM, Dmitry Lomov <dslomov@chromium.org> wrote:
>
>> 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).
>>
>
> This supports the subject line "postMessage is the new wtf"
>

The subject isn't very productive approach to asking questions.

This API, and the differences between window.postMessage and
port.postMessage, is well-documented in Web Messaging.
http://dev.w3.org/html5/postmsg/#posting-messages



> 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.
>>
>
> Can you provide a reference for this? I'm unable to locate anything that
> covers these semantics.
>

Please see the definition of postMessage, which transfers objects (search
for the text "transferring the object x"), and the text: "To transfer a
MessagePort object old to a new owner owner, ...", which defines what
transferring does in the case of MessagePort.

 --
Glenn Maynard