[whatwg] postMessage() issues

[Jonas Sicking]

Peter Kasting wrote:
> On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <jonas at sicking.cc> 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