Re: Sync API for workers

Could we change the method name under discussion to `postMessageSync`
instead of `postSyncMessage`? I know they're not grammatically equivalent
but I've always found the *Sync suffixes used on pertinent Node.js APIs to
be much more intuitive than trying to guess which position within a string
of words it should take.

Not sure on prior art within the web platform.
On Oct 14, 2013 4:59 AM, "Jonas Sicking" <jonas@sicking.cc> wrote:

> On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller
> <dteller@mozilla.com> wrote:
> > Let me introduce the first sketch of a variant. The general idea is to
> > add a |postSyncMessage|
> >
> > We extend DedicatedWorkerGlobalScope and MessageEvent as follows:
> >
> > interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
> >   void postMessage(any message, optional sequence<Transferable>
> transfer);
> >   any postSyncMessage(any message, optional sequence<Transferable>
> > transfer);
> > };
> >
> > interface SyncMessageEvent : MessageEvent {
> >   void reply(optional any message, optional sequence<Transferable>
> > transfer);
> > };
>
> This API was suggested by Olli way up in this thread. It has a few
> downsides:
>
> 1. It only allows a single synchronous message channel. That means
> that if you have several libraries that all need synchronous
> communication with the parent they have to coordinate on some way to
> distinguish each others messages. The fact that Gecko hasn't had
> MessageChannel support has resulted in the same problem for
> asynchronous communication and that has been a big headache for
> developers.
> 2. It doesn't support "streaming" return values. I.e. you can't send
> multiple return values from a single postSyncMessage call.
> 3. It doesn't allow direct synchronous communication between a worker
> and the workers "grand parent". Everything single message has to be
> individually routed through the parent.
> 4. What happens if you have multiple eventlisteners in the parent and
> several of them call .reply()?
>
> I wouldn't say that all of these are killer issues. I do think the
> first one is though. And the other three are clearly downsides.
>
> All in all I think the added complexity in the later proposal is worth it.
>
> / Jonas
>
>