RE: [whatwg] postMessage() issues

Jonas Sicking wrote

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



I agree with Jonas. The spec needs to call out the behavior here. Leaving it undefined will confuse developers. There are a few concerns on cross process boundary/tab communication with sync since it 'couples' entities across tabs/instances of the browser so that if one hangs the other one will be taken down as well. On the other hand, the cross frame messaging technique with the fragment today does not provide a way to do this and our current synchronous implementation of cross document messaging provides parity. Not to mention it's difficult for us to change our implementation at this stage. I'm a bit swamped right now and can't provide our team-wide stance on this just yet. In the absence of current guidance in the spec I'd like to talk to my team further on the cross tab/instance messaging  scenario and the sync/async model. I'll try to get back within 2 weeks with a MS position here.



Jonas Sicking Wrote

" No one is proposing an api where postMessage is returning an actual result though, right? And that would definitely require synchronous dispatch."



I have not heard of an actual result being proposed. We also have to be careful about returning failures for security reasons and fail silently, which if I'm not mistaken is what the spec does today (fails silently).



In response to Aaron Boodman

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



Jonas Sicking Wrote

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



This removes the need to store any state and makes it simpler for the developer.







-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc]
Sent: Monday, April 21, 2008 11:08 AM
To: Aaron Boodman
Cc: Maciej Stachowiak; whatwg@whatwg.org; IE8 Core AJAX SWAT Team; Ian Hickson; Sunava Dutta; public-html-comments@w3.org
Subject: Re: [whatwg] postMessage() issues



Aaron Boodman wrote:

> On Wed, Apr 16, 2008 at 3:17 PM, Jonas Sicking <jonas@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