W3C home > Mailing lists > Public > public-html-comments@w3.org > April 2008

Re: [whatwg] postMessage() issues

From: Ojan Vafai <ojan.vafai@gmail.com>
Date: Thu, 17 Apr 2008 19:22:36 -0700
Message-ID: <1e6fc0e0804171922k5e4a6a59l9c3465f9c19c0367@mail.gmail.com>
To: "Aaron Boodman" <aa@google.com>
Cc: "Jonas Sicking" <jonas@sicking.cc>, "IE8 Core AJAX SWAT Team" <ieajax@microsoft.com>, "Maciej Stachowiak" <mjs@apple.com>, whatwg@whatwg.org, "Ian Hickson" <ian@hixie.ch>, "Sunava Dutta" <sunavad@windows.microsoft.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>
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.



> - a
Received on Friday, 18 April 2008 21:55:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:24 UTC