[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

[Jonas Sicking]

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