[whatwg] postMessage() issues

[Maciej Stachowiak]

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.
- Processing a reply synchronously is awkward in any case, since you  
need a callback.
- 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.
- 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.
- 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.

However, I don't feel very strongly about this and I would consider  
synchronous postMessage acceptable.

(Note also that Eric Seidel, who commented on this issue earlier, was  
also giving his feedback as a WebKit developer, though in both cases  
we speak mainly for ourselves and not as an official position of the  
whole project.)

Regards,
Maciej