[whatwg] postMessage() issues

[Jonas Sicking]

So one thing I should note first of all is that the implementation that
is currently in the Firefox 3 betas are synchronous. It is unlikely that
we can get this changed by final shipping since we are more or less in
code freeze already.

Of course, we implemented this knowing that it's part of HTML5 which is
nowhere near complete, so obviously we were aware that it might change.
However it might mean that developers will have to put in workarounds in
order to support the FF3 release :(

Maciej Stachowiak wrote:
> On Apr 15, 2008, at 5:10 PM, Ian Hickson wrote:
>> At the moment people have proposed that the API be asynchronous, and some
>> people are ok with that, but other people are strongly opposed to it. 
>> I am
>> not sure where to go with this. Input from other browser vendors --
>> yourself and WebKit in particular -- would be very useful. Right now the
>> API is synchronous, and Mozilla reps have indicated they strongly prefer
>> that, Opera reps have indicated they don't mind, and Gears reps have
>> indicated they'd rather it be async.
> 
> I think async is better, for the following reasons:
> 
> - PostMessage seems to imply a message queue model.

I think this is a pretty weak argument one way or another. It's IMHO
much more important that we create an API that is the most usable that
we can make it.

> - Processing a reply synchronously is awkward in any case, since you 
> need a callback.

I'm not sure I follow this argument, I actually come to the opposite
conclusion.

Say that a page is communicating with multiple iframes using
postMessage, and expect replies from all of them.

If postMessage is synchronous it is easy to associate a given "reply"
with a given postMessage call, it's simply the reply you get between the
time you make the postMessage call and when it returns. So you could 
install a generic listener for the message event and let the listener 
set a global variable. Then you just do a postMessage and pick up the 
reply from the global variable.

If postMessage is asynchronous you need to agree on using some 
identifier in the messages, or you have to use the pipes mechanism for 
all communication. Granted, with javascript generators you can almost 
get the same behavior as for synchronous calling, but that is non-trivial.

> - This is different from event dispatch because replies are expected to 
> be common; two way communication channels like postMessage make more 
> sense as asynchronous, while event dispatch is typically one-way.

Why does two-way communication make more sense asynchronous? See above 
for why responses are more complicated with async communication.

> - Saying that runaway two-way messaging should be handled by a "slow 
> script" dialog seems weak to me, compared to making the mechanism 
> intrinsically resistant to runaway behavior.

I'm not sure why we think that runaway two-way messaging is going to be 
a likely problem. Do we have runaway two-way function calling as a big 
problem now?

I would in fact say that async calling would be more likely to cause 
runaway cross messaging. If you have sync calling you'll quickly recurse 
to death and notice an exception being thrown. With async calling you 
simply hog the CPU.

> - Making new communication APIs async makes it more practical to 
> partition browsing contexts into separate threads, processes, operation 
> queues, or other concurrency mechanisms (within the limitations of what 
> kind of things must be serialized.
> - We can foresee that workers in the style of Gears will be a future use 
> case for postMessage; in that case, it clearly must be async.

These both are good points.

/ Jonas