<div class="gmail_quote">On Wed, Apr 16, 2008 at 6:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Peter Kasting wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

</blockquote></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br></div>
No one is proposing an api where postMessage is returning an actual result though, right? And that would definitely require synchronous dispatch.</blockquote><div><br></div><div>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 :)</div>

<div><br></div><div>To follow up on other points in your email:</div><div><br></div><div>* 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.</div>

<div><br></div><div>* 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.)</div>
<div><br></div><div>PK</div>
</div>