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
