Re: [whatwg] postMessage() issues

On Thu, Apr 17, 2008 at 10:39 AM, Aaron Boodman <aa@google.com> 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).


I don't understand this argument. Why do you need an identifier? Doesn't
e.source point to the frame in question?


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


+1

Ojan


>
>
>
> - a
>