[whatwg] Request: window.postMessage should be async

On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden
<jwalden+whatwg at mit.edu<jwalden%2Bwhatwg 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 some reason, you're
really sold on a sync API, and you're willing to impose whatever costs it
takes on both callers and callees in order to push that through.  But I
don't see a win here.  Make the API async and no one has to do any of this
work, and web apps are immediately simpler and 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080405/00634665/attachment.htm>

Received on Saturday, 5 April 2008 15:51:53 UTC