[whatwg] postMessage() issues

[Jonas Sicking]

Aaron Boodman wrote:
> On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Maciej Stachowiak wrote:
>>> - Processing a reply synchronously is awkward in any case, since you need
>>> a callback.
>> I'm not sure I follow this argument, I actually come to the opposite
>> conclusion.
>>
>> Say that a page is communicating with multiple iframes using
>> postMessage, and expect replies from all of them.
>>
>> If postMessage is synchronous it is easy to associate a given "reply"
>> with a given postMessage call, it's simply the reply you get between the
>> time you make the postMessage call and when it returns. So you could install
>> a generic listener for the message event and let the listener set a global
>> variable. Then you just do a postMessage and pick up the reply from the
>> global variable.
>>
>> If postMessage is asynchronous you need to agree on using some identifier in
>> the messages, or you have to use the pipes mechanism for all communication.
>> Granted, with javascript generators you can almost get the same behavior as
>> for synchronous calling, but that is non-trivial.
> 
> This is a really good argument. FWIW, I had not considered the case of
> coordinating between multiple iframes. That does make the async
> version significantly more complex.
> 
> IMO, the tradeoff is still worth it, though. And in the future, with
> something like Hixie's messaging proposal, this problem will go away
> (because you'll have stateful objects that represent a conversation).

That's still somewhat painful when you are sending multiple messages 
back and forth since you have to stow away state and resume where you 
were which can be a big hassle.

Certainly not impossible to deal with for a developer, but more complicated.

>> So one thing I should note first of all is that the implementation that
>> is currently in the Firefox 3 betas are synchronous. It is unlikely that
>> we can get this changed by final shipping since we are more or less in
>> code freeze already.
>>
>> Of course, we implemented this knowing that it's part of HTML5 which is
>> nowhere near complete, so obviously we were aware that it might change.
>> However it might mean that developers will have to put in workarounds in
>> order to support the FF3 release :(
> 
> What about if we just left the sync/async-ness unspecified for the
> first version of postMessage. In practice this means that
> implementations might be incompatible, but I don't the workarounds are
> that big a deal. Authors have this problem already today with XHR in
> certain edge cases (sometimes onreadystatechange is not asynchronous)?
> 
> In the future, when the messaging proposal evolves, we tighten it down
> and make it async.

I think that's a really bad idea. Async vs. sync has a huge impact on 
how to use the API, it's very likely that anyone using the API will 
break if the implementation changes either way on this. So basically 
there is very little advantage over specifying nothing at all.

/ Jonas