Re: [whatwg] postMessage() issues
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
Re: [whatwg] postMessage() issues
On Wed, Apr 16, 2008 at 6:41 PM, Jonas Sicking [EMAIL PROTECTED] wrote: Peter Kasting wrote: 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. To be more clear, the intent of my statement was if you're going to make it synchronous, then really make it synchronous and have postMessage return a value. Or else make it fully asynchronous. But the current state is synchronous yet doesn't return a value, so you don't get the best of either world. I feel like that was a point raised before, but I can't remember :) To follow up on other points in your email: * I too am very interested in Maciej's points re: partitioning browsing contexts and Gears-style workers. Without concrete examples of how these would work today I haven't had any compelling arguments to make on this list, but these sorts of things are driving some of my concerns about being locked into a synchronous API. Async APIs seem more future-proof in a world where we start supporting more threading/process models in web apps or make UAs multiprocess (as IE8 seems to be doing with their tab crash recovery system). I am aware that there are existing synchronization/serialization requirements, but perhaps they can be solved; certainly adding more won't make the task easier. Perhaps Microsoft has insight here. * On the other-hand, perhaps we can just ship Fx3 as-is, and if down the road we become convinced that the API needs to change, we change it. That's what happened with global/local storage and Firefox 2, right? (Or I suppose if Mozilla is really concerned about this issue, postMessage could be pulled from Fx3 as cross-domain XHR was, though that seems pretty drastic.) PK
Re: [whatwg] postMessage() issues
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). 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
Re: [whatwg] postMessage() issues
On Thu, Apr 17, 2008 at 7:22 PM, Ojan Vafai [EMAIL PROTECTED] wrote: 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). I don't understand this argument. Why do you need an identifier? Doesn't e.source point to the frame in question? Oh good point, I take it back. - a
Re: [whatwg] postMessage() issues
Hi! I agree with everything Maciej said, but I'm rather impartial. The word post implies posting something to a queue of messages, like we've seen in other programming APIs. There are use cases for both sync and async API, so we should support both. We could have either a new parameter for postMessage, like with have for XHR, which defines the behavior (if async or not), or we could have two functions postMessage asynchronous and sendMessage synchronous. Then everyone would be happy. Thank you. 2008/4/16, Maciej Stachowiak [EMAIL PROTECTED]: On Apr 15, 2008, at 5:10 PM, Ian Hickson wrote: At the moment people have proposed that the API be asynchronous, and some people are ok with that, but other people are strongly opposed to it. I am not sure where to go with this. Input from other browser vendors -- yourself and WebKit in particular -- would be very useful. Right now the API is synchronous, and Mozilla reps have indicated they strongly prefer that, Opera reps have indicated they don't mind, and Gears reps have indicated they'd rather it be async. I think async is better, for the following reasons: - PostMessage seems to imply a message queue model. - Processing a reply synchronously is awkward in any case, since you need a callback. - 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. - Saying that runaway two-way messaging should be handled by a slow script dialog seems weak to me, compared to making the mechanism intrinsically resistant to runaway behavior. - Making new communication APIs async makes it more practical to partition browsing contexts into separate threads, processes, operation queues, or other concurrency mechanisms (within the limitations of what kind of things must be serialized. - We can foresee that workers in the style of Gears will be a future use case for postMessage; in that case, it clearly must be async. However, I don't feel very strongly about this and I would consider synchronous postMessage acceptable. (Note also that Eric Seidel, who commented on this issue earlier, was also giving his feedback as a WebKit developer, though in both cases we speak mainly for ourselves and not as an official position of the whole project.) Regards, Maciej
Re: [whatwg] postMessage() issues
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 :( Maciej Stachowiak wrote: On Apr 15, 2008, at 5:10 PM, Ian Hickson wrote: At the moment people have proposed that the API be asynchronous, and some people are ok with that, but other people are strongly opposed to it. I am not sure where to go with this. Input from other browser vendors -- yourself and WebKit in particular -- would be very useful. Right now the API is synchronous, and Mozilla reps have indicated they strongly prefer that, Opera reps have indicated they don't mind, and Gears reps have indicated they'd rather it be async. I think async is better, for the following reasons: - PostMessage seems to imply a message queue model. I think this is a pretty weak argument one way or another. It's IMHO much more important that we create an API that is the most usable that we can make it. - 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 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. - Saying that runaway two-way messaging should be handled by a slow script dialog seems weak to me, compared to making the mechanism intrinsically resistant to runaway behavior. I'm not sure why we think that runaway two-way messaging is going to be a likely problem. Do we have runaway two-way function calling as a big problem now? I would in fact say that async calling would be more likely to cause runaway cross messaging. If you have sync calling you'll quickly recurse to death and notice an exception being thrown. With async calling you simply hog the CPU. - Making new communication APIs async makes it more practical to partition browsing contexts into separate threads, processes, operation queues, or other concurrency mechanisms (within the limitations of what kind of things must be serialized. - We can foresee that workers in the style of Gears will be a future use case for postMessage; in that case, it clearly must be async. These both are good points. / Jonas
Re: [whatwg] postMessage() issues
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. - 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. PK
Re: [whatwg] postMessage() issues
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
[whatwg] postMessage() issues
On Tue, 15 Apr 2008, Sunava Dutta wrote: Just following up to my email a few weeks back regarding cross document messaging. http://lists.w3.org/Archives/Public/public-html-comments/2008Feb/0024.html We'd love to know whether our proposed changes here (in the rewrite) can be accepted or not. Either way, we intend on conforming to the standard and it's important to us to know the decision here. I haven't heard a response from an HTML 5.0 member yet. (Although Jeff Walden from MIT was gracious enough to share his thoughts) I will deal with this feedback ASAP. For your convenience, I've isolated the core of the request. Thanks, that helps -- I was studying the text you proposed and couldn't work out what the new text was! For the postMessage (message, origin) method we would recommend the parameter be called postMessage(message, targetOrigin) since it's easier to understand what it is. I'll be happy to make that change. In addition, as our Beta 1 launch indicates, we're very keen on shipping this feature in IE8. Any indication on potential changes to the draft in this area as soon as possible will help us ship a release that's in harmony with the latest developments. Thanks for letting me know. I shall prioritise this. On Tue, 15 Apr 2008, Sunava Dutta wrote: Looking at the current draft for cross document messaginghttp://www.w3.org/html/wg/html5/#crossDocumentMessages, I was wondering if there is any guidance on the scope for postMessage. Specifically, does the postMessage send data across tab/process boundaries? (If there is guidance here in an updated draft I apologize, can't seem to find it!) Yes, it is supposed to work cross-tab (and cross-process, if tabs are in different processes). Because the postMessage() API is synchronous, this also implies that all scripts across all processes that can in any way communicate with each other have to be synchronous, so there has to be an inter-process lock to keep the scripts from running at the same time (otherwise you can get two tabs try to talk to each other at the same time and the entire thing would lock). At the moment people have proposed that the API be asynchronous, and some people are ok with that, but other people are strongly opposed to it. I am not sure where to go with this. Input from other browser vendors -- yourself and WebKit in particular -- would be very useful. Right now the API is synchronous, and Mozilla reps have indicated they strongly prefer that, Opera reps have indicated they don't mind, and Gears reps have indicated they'd rather it be async. Here are a few arguments/counter-arguments that come to mind... * Against allowing this: Limiting it to the same Tab would make it equivalent to IFRAM hack in IE functionality wise.( http://tagneto.blogspot.com/2006/06/cross-domain-frame-communication-with.html) o It would drastically reduce our attack surface without reducing its usefulness too much. * For allowing this: Granted it would be even more powerful if we allow postMessage to go across thread/process boundary. Ensuring this feature is consistent with other DOM reach-ability will be architecturally sound. If a web developer can set window.location on a given target, being able to post a message to it would make sense. I'm excited to hear thoughts here! Indeed, the idea is that it be similar in access to window.location. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
