- From: Aaron Boodman <aa@google.com>
- Date: Wed, 24 Sep 2008 20:27:48 +0200
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. np. > 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
Received on Wednesday, 24 September 2008 11:27:48 UTC