Peter Kasting wrote:
On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <[EMAIL PROTECTED]> 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.
I think the argument assumed you were communicating with a single frame
in the common case, in which case the current API is more awkward than
one in which the postMessage() call itself returns the response,
requiring no listener at all.
No one is proposing an api where postMessage is returning an actual
result though, right? And that would definitely require synchronous
dispatch.
- This is different from event dispatch because replies are
expected to be common; two way communication channels like
postMessage make more sense as asynchronous, while event
dispatch is typically one-way.
Why does two-way communication make more sense asynchronous? See
above for why responses are more complicated with async communication.
From one of Aaron Boodman's mails: if you're doing a postMessage()
response back to a frame when it calls you, then the original frame will
get called with your response before its original postMessage() actually
returns. This nesting feels bizarre compared to a more linear "I send a
message, then I get a response" flow.
Yes, the nesting does feel a bit unusual. But it still seems easier to
me to use since you'll get access to a result right after the call to
postMessage, similar to a normal function call. No need to stow away any
state you are currently carrying and then bring that back once you get a
message back.
/ Jonas
