Jonas Sicking wrote:
Here's an example in code:
// dedicated workers (outside)
var worker = new Worker("foo.js");
var port = worker.connect();
port.onmessage = function() { }
port.postMessage("ping");
// dedicated workers (inside)
onconnect = function(e) {
e.port.onmessage = function(e) {
e.port.postMessage("pong");
}
}
Shared workers are exactly the same except the constructor is
SharedWorker("foo.js", "foo");
Note that I do not think it is necessary to implement this all at
once. For one, the SharedWorker constructor could easily be punted for
future releases.
Thoughts?
My main concern is that I think this makes the most simple use case a
bit too complicated. In the case when you have a dedicated worker that
you want to offload some calculations too you need quite a bit of code
to set up that communication.
With the current API you'd do the following:
main.js:
w = new Worker('worker.js');
w.postMessage(17);
w.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onmessage = function(e) {
postMessage(heavyCalculation(e.data));
}
With the proposed API:
main.js:
w = new Worker('worker.js');
p = w.connect();
p.postMessage(17);
p.onmessage = function(e) {
answer = e.data;
}
worker.js:
function heavyCalulation(inValue) {
...
}
onconnect = function(e) {
e.port.onmessage = function(e2) {
e.port.postMessage(heavyCalulation(e2.data));
}
}
This complexity I feel is extra bad since I suspect the simple case is
going to be the common case (I know we disagree there). I especially
dislike the fact that you have to wait for two events, first a 'connect'
event and then the actual message event. This seems overly complex for
the simple case of simply wanting to use a single communication channel
with a dedicated worker. And even though there isn't that much more code
in my example above, it took significantly more effort to get it right
given the nested two handlers that were needed.
So I think we should keep the simple case of a dedicated worker and a
single communication channel as simple as possible. This means that I
think we should keep postMessage/onmessage available on the dedicated
worker directly, as well as the dedicated worker global scope.
As an added bonus this keeps things very similar to message passing
between windows.
I'm fine with removing things like 'startConversation' and the implicit
call to connect() on shared workers. 'startConversation' isn't really a
new communication mechanism, but rather a convenience method on top of
postMessage.
So Hixie brought up a good point on IRC, there really is only one
communication mechanism, which is postMessage/onmessage.
I'd note that if we drop startConversation (which it seems like no-one
is opposing) then all proposals have two 'communication' mechanisms:
postMessage and connect.
With Aarons proposal you have to both for a shared worker and a
dedicated worker use both mechanisms; first call connect() and then call
postMessage(). If keep postMessage on the dedicated worker the only
difference is that for a dedicated worker you skip the connect() and go
directly to postMessage.
/ Jonas
