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" <jo...@sicking.cc> wrote: > On Mon, Oct 14, 2013 at 2:33 AM, David Rajchenbach-Teller > <dtel...@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 > >