- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 15 Apr 2008 17:42:49 -0700
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
Received on Tuesday, 15 April 2008 17:42:49 UTC