[whatwg] postMessage() issues

[João Eiras]

Hi!

I agree with everything Maciej said, but I'm rather impartial.
The word post implies posting something to a queue of messages, like
we've seen in other programming APIs.

There are use cases for both sync and async API, so we should support
both. We could have either a new parameter for postMessage, like with
have for XHR, which defines the behavior (if async or not), or we
could have two functions postMessage asynchronous and sendMessage
synchronous.
Then everyone would be happy.

Thank you.



2008/4/16, Maciej Stachowiak <mjs at apple.com>:
>
>  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
>
>