Re: [whatwg] postMessage() issues

On Wed, Apr 16, 2008 at 6:41 PM, Jonas Sicking <jonas@sicking.cc> 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