[whatwg] workers

Aaron Boodman aa at google.com
Wed Sep 24 11:27:48 PDT 2008

On Wed, Sep 24, 2008 at 6:26 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> Sorry about the slow feedback, has been on vacation most of the time.


> So first off I don't think we can remove the ability to pass
> MessagePorts around. This ability exists in Window.postMessage already
> per spec so nothing that the workers spec does can change that. Also, if
> we think the "pass-around-ability" of ports affect how much we want to
> use them, punting the pass-around-ability to the second version of the
> spec shouldn't really affect how we design the API as we'll arrive at
> the second version sooner or later.

I'm thinking of MessageChannels, MessagePorts, and Workers as one new
task for implementors, since as far as I know, nobody has shipped any
of these yet.

> So given that, I prefer the current API. I think that for the common
> case of non-shared workers it makes for a simpler API. The fact that you
> argue that there should be a catch-all global onmessage inside the worker
> seems to indicate that using onconnect is lacking somewhere.
> I agree with the benefit of keeping shared vs. non-shared workers as similar
> as possible. However I feel that the complexities that come with always
> using ports for non-shared workers outweighs it.

In the current design, there are three separate mechanisms to connect
to and communicate with a worker:

a) DedicatedWorker::sendMessage() + DedicatedWorkerGlobalScope::onmessage

b) DedicatedWorker::startConversation() + DedicatedWorkerGlobalScope::onmessage

c) new SharedWorker() + SharedWorkerGlobalScope::onconnect

I would like to combine all of these into one common mechanism:

- Create a worker using either new Worker() or new SharedWorker()
- Call connect() to get a channel
- Inside the worker, listen for onconnect, then receive messages using
the port's onmessage event

This consolidates all the use cases into one common mechanism. It is
true that it makes it a little extra work for the very simplest use
cases. But I think that 'conversations' are important enough to
warrant making them the only way to communicate with workers.

- a

More information about the whatwg mailing list