[whatwg] postMessage() issues

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

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


- a

Received on Thursday, 17 April 2008 10:39:47 UTC