Aaron Boodman wrote:
Here is one more point on the async vs sync thing.
In my opinion, one of the most compelling reasons to make an API
synchronous instead of asynchronous is convenience. This is why I was
so passionate about having a synchronous database API: getting the
result of a call via
- Original Message
From: Peter Kasting [EMAIL PROTECTED]
To: Jeff Walden [EMAIL PROTECTED]
Cc: whatwg@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 [EMAIL PROTECTED] wrote
On Sun, Apr 6, 2008 at 1:52 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
There doesn't seem to be any advantage to it.
I take it back, there is one advantage, which Jeff brought up:
function realMessageHandler(messageEvent) {
// handle the message...
// and, reply to the message
Here is one more point on the async vs sync thing.
In my opinion, one of the most compelling reasons to make an API
synchronous instead of asynchronous is convenience. This is why I was
so passionate about having a synchronous database API: getting the
result of a call via a return value is much
On Sun, Apr 6, 2008 at 1:52 AM, Aaron Boodman [EMAIL PROTECTED] wrote:
We have on one hand authors with reasons
(however edge casey you may believe them to be) they would prefer the
API be asynchronous,
Here's another problem an async API would automatically address:
On Sun, 06 Apr 2008 11:41:20 +0200, Peter Kasting [EMAIL PROTECTED]
wrote:
Here's another problem an async API would automatically address:
https://bugzilla.mozilla.org/show_bug.cgi?id=416912
FWIW, Opera is ok either way. I personally think it doesn't make much
sense for this to be
Peter Kasting wrote:
Here's another problem an async API would automatically address:
https://bugzilla.mozilla.org/show_bug.cgi?id=416912
That *should* be handled by a slow-script dialog, and the fact that it isn't is
simply a bug. That the bug is triggered using postMessage is in my opinion
(Apologies if the threading on this gets messed up. I was not subscribed to
the list when the original message was sent.)
I want to paint Eric's scenario more strongly, because it seems like people
think if it would rarely blow up then it doesn't matter.
If you want to handle _any_ request sent
Peter,
On Sat, Apr 5, 2008 at 12:38 AM, Peter Kasting [EMAIL PROTECTED] wrote:
Or, if you like, take the position that the argument should stay optional,
and if someone for some reason doesn't have to care about security (?!),
they can avoid passing it. Although I'm not sure this is a
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
On Sat, Apr 5, 2008 at 2:19 PM, Jeff Walden
[EMAIL PROTECTED][EMAIL PROTECTED]
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
On Fri, 04 Apr 2008 23:04:30 +0200, Eric Seidel [EMAIL PROTECTED] wrote:
Anyway, I'm not the foremost expert here, but I was reading HTML5 last
week and encountered this sync postMessage() requirement, which seemed
like a bad idea.
It doesn't make sense to change this given that all
On Fri, Apr 4, 2008 at 2:39 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
It doesn't make sense to change this given that all synthesized event
dispatching is synchronous. I don't think postMessage() should be different.
It seems a little different to me. PostMesasge events are fired in
Eric Seidel wrote:
1. JS content authors will want an async API.
Sometimes, for the large applications; small apps won't care. As you note, the
workaround of immediately packaging up a setTimeout continuation isn't
difficult. I tend to think worrying about the N-1 case is designing a bit
Anne-
Thanks for the reply.
I see window.postMessage as different from element.dispatchEvent. The JS
author has control over the JS code executed as a result of their
dispatchEvent call. JS author does not have control over code executed by
window.postMessage (either before and after, or
On Sat, 05 Apr 2008 00:03:58 +0200, Aaron Boodman [EMAIL PROTECTED] wrote:
On Fri, Apr 4, 2008 at 2:39 PM, Anne van Kesteren [EMAIL PROTECTED]
wrote:
It doesn't make sense to change this given that all synthesized event
dispatching is synchronous. I don't think postMessage() should be
16 matches
Mail list logo
