Aaron Boodman wrote:
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <[EMAIL PROTECTED]> 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
