[whatwg] Request: window.postMessage should be async

Communication between two frames now is synchronous, and in my opinion, necessarily so. I believe (and I could be wrong) the intent of postMessage() was to allow similar access between frames of different origins as there is between frames of the same origin. If that's the case, then making postMessage() synchronous makes sense...if you're running into cross-frame communication issues currently, this API doesn't introduce any more issues though it admittedly wouldn't fix any either. The question is: was it really designed to? Again, my belief is that the answer is no.

-Nicholas

----- Original Message ----
From: Peter Kasting <pkasting@google.com>
To: Jeff Walden <jwalden+whatwg at mit.edu>
Cc: whatwg at lists.whatwg.org
Sent: Saturday, April 5, 2008 3:51:53 PM
Subject: Re: [whatwg] Request: window.postMessage should be async

On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden <jwalden+whatwg at mit.edu> wrote:
Peter Kasting wrote:
It doesn't matter if the stack will not _commonly_ be too deep, or if it isn't too deep for the callers that you know about right now -- it might be too deep at some point (after someone else changes the caller code, for example), and your sync handler will blow up.


So put it in the contract for the API you're designing on top of postMessage that you shouldn't call the method without some generous number of frames available.  (Doesn't assuming you'll need to consume lots of stack frames work against your argument that postMessage receivers will usually do computation out-of-band anyway?)  I don't see why this problem requires a technical solution rather than a social one.  (I should have mentioned this in the first message, thanks for prompting me to bring it up now.)
So, your solution is, all developers writing postMessage-based APIs have to publish a contract, which is not enforced by any tooling but is merely part of some documentation alongside their API, that says how many stack frames they need?  That seems like there are all kinds of risks of forgetting to do it, users ignoring it, etc.  Why not just do the right thing naturally under the hood?  Technical solutions that prevent misuse are always better than social ones, as you yourself originally argued on the security front.

Here's another interesting case: what if my postMessage handler is a middleman that needs to itself postMessage to another target (a third party, or back to the original source)?  Now I can't guarantee I have sufficient stack depth even if I care and know what my callee is expecting.


And the very sorts of things you'd want postMessage for are frequently cases where others will write mashups and use your code in ways you hadn't planned.


No, but *they* plan how they're going to use it, and they can adjust to not call with near-full stacks.
Again, you're imposing extra effort on a potentially large number of callers, whose authors are at various skill levels, for what appears to me to be little gain.  When Yahoo publishes some convenient postMessage()-based functionality, why should I have to understand anything about the requirements it imposes on me?  Why can't I treat it as a black box?

The same argument goes for running time-- if I don't know how long the callsite might take to execute, the only way I can guarantee responsiveness with a sync API is to do something like use Google Gears to get a WorkerPool object so I can effectively thread my JS, and then make my synchronous call in an async way while simultaneoulsy continuing my other processing.  An async API, on the other hand, is significantly less risky because I'm guaranteed that I can't block for arbitrary periods of time no matter what the far side does.  In most situations I can think of that use postMessage, it would also fit much more naturally into the code I'd be writing.


 All that happens is an exception, and you can catch and deal with it in the rare case that it happens.
Potentially rare in frequency, assuming you're not running on pocket IE, but not in terms of call site structure when one side or the other is opaque -- callers would _always_ need to catch this exception and do something.


If you're still not convinced that coders would care, remember that stack depths vary by interpreter, too.  I believe in pocket IE you have a ridiculously small stack depth [12?].


This surprises me, but realistically, no device is going to be able to afford to have such a low stack depth going forward anyway.
So, the real world is not a problem because you assume manufacturers are going to change it?  What past evidence makes you think this will be true?  I agree that probably someday we will be in a world where this is a case, but that day may be many years away.  I'm not prepared to ignore that market until it happens to fit my conception of what it ought to be.
 
 I don't think we should penalize tomorrow for a limitation of today.
What penalty are you imposing on tomorrow by making the API async?  It's an easier, more natural API that is safer, more robust, and easier to implement.  That doesn't sound like a penalty to me.

The general theme I sense in your argument is that for somereason, you're really sold on a sync API, and you're willing to imposewhatever costs it takes on both callers and callees in order to pushthat through.  But I don't see a win here.  Make the API async and noone has to do any of this work, and web apps are immediately simplerand more robust.
 
I don't think a decent-sized percentage of web developers worry about stack overflow significantly more often than they worry about it from thinkos that accidentally cause infinite recursion.

And I'm arguing that we should build an API that doesn't _force_ them to think about it more often than they do now, either.  Especially when this functionality will increase the frequency of the sort of deeper call chains that trigger this problem in the first place.  It's much less common to deeply nest direct function calls than it might be to stack postMessage()-based modules onto each other, block by block, each doing a little more work, until suddenly things break.  Imagine if in UNIX I had an arbitrary limit of how many things I could hook together via pipes, and that limit was based on some hidden aspect of how each executable performed its work.  Would you say that simply publishing a number in all man pages, and requiring users to sum those numbers when constructing command lines, was an acceptable solution?  What about making users wrap each executable name in some kind of exception handler?

A sync postMessage() API seems about as reasonable as an async one when you're only looking at toy code, where caller and callee know each other, and neither is doing any real work.  When you start chaining objects together, using third-party code, hooking to public objects provided by Google, Yahoo, and others, and building the sorts of interesting functionality that we want to encourage, it just doesn't make sense to me.

PK






      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080406/53996269/attachment.htm>

Received on Sunday, 6 April 2008 01:13:27 UTC