[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

[Jonas Sicking]

> Here are my preference on changes, in descending order:
> 
>> * Add a connect() method to Worker and/or SharedWorker
>> There has been lots of talk about this, but I'm still confused as to
>> what the exact proposals are due to lack of details. But here is my
>> interpretation
>> Details:
>>  - Make instantiating a SharedWorker *not* fire a 'connect' event automatically.
>>  - Remove the .port property from SharedWorker
>>  - Remove the postMessage/onmessage functions from Worker and
>> DedicatedWorkerGlobalScope
>>  - Add a onconnect property on WorkerGlobalScope
>>  - Add a connect() method on AbstractWorker. The function fires a
>> 'connect' even on the WorkerGlobalScope, the event has a .port
>> property which is a MessagePort. This MessagePort is entangled with
>> another MessagePort which is the value from the connect() function.
>>
>> Comments:
>> Compared to just doing the other above proposals I think this adds
>> needless complexion for value that I don't quite see. If you want to
>> have several 'conversations', I.e. several separate MessagePorts, with
>> a dedicated worker you can use postMessage and |new MessageChannel|
>> (or the startConversation shorthand) to accomplish that. If you want
>> several conversations with a dedicated worker you can do the same
>> thing, or even call |new SharedWorker| multiple times.
> 
> I think this is the best API because it offers the most functionality
> with the smallest area. I also like that the API for dedicated and
> shared workers is identical because it means that one you learn to use
> dedicated workers, you already know how to use shared workers.

Comparing to doing the other set of changes the differences in API are 
as follows:

  - Add a 'connect()' method on AbstractWorker which must be called every
    time after instantiating a worker.
  - The postMessage/onmessage functions are moved from the worker object
    to the port object.

To me this seems like strictly a bigger API. As far as functionality 
goes the differences are as follows:

  - You have to deal with two separate objects, the port and the worker.
  - You can create multiple communication channels with a worker by
    calling connect() multiple times.

Only the second thing here seems like a win. And only for dedicated 
workers since for shared workers you can simply call |new SharedWorker| 
multiple times if you want multiple communication channels.

So it seems to me like the pros and cons fall out as:
  Pros:
    - Easier to create multiple connection channels to dedicated workers
  Cons:
    - Bigger API (an extra connect() function)
    - More code required (an extra call to connect() required)
    - More objects (port and worker)


To me the cons outweigh the pros here. Is there a goal with connect() 
that I'm missing?


>> * Remove startConversation
>> Details:
>> Simply remove the startConversaion function on all interfaces where it
>> is defined. Since it doesn't define any new events no other changes
>> are needed.
>>
>> Comments:
>> There seemed to be opinions before on that it should definitely be
>> removed, however it sounds like that is less the case now. I don't
>> really care about this one. startConversation is just a convenience
>> function on top of postMessage anyway. If there still is any
>> disagreement about its neccessity or the fact that it adds to that we
>> have too many communication mechanisms i'd prefer we remove it for now
>> and then discuss it once we've agreed on the rest of the API, or we
>> can let it be for this version of the spec. Others have commented that
>> startConversation is a red herring in these discussions, I agree.
>>  (This would be no problem for us since we don't implement
>> startConversation yet).
> 
> If we don't make the above change, I think that we should remove
> startConversation(). It doesn't offer enough different functionality
> over passing a |new MessageChannel().port2| to be worth the extra API
> IMO.

No, this is *exactly* the same functionality as passing |new 
MessageChannel().port2| through postMessage.

Why does *not* making the "above change" (I assume adding connect()?) 
mean that we should remove startConversaion? I would have thought that 
the opposite would be true. Keeping startConversation makes much sense 
if we don't have connect() as both functions set up a 'conversation'.


>> * Make the external API for shared workers that of the current dedicated worker
...
> I don't have a strong opinion on this.
> 
>> * Make dedicated workers receive a 'connect' event when they are created
...
> I don't have a strong opinion on this.

Hmm.. I thought that the reason we are having this whole discussion was 
because there was dislike around the fact that dedicated and shared 
workers have different APIs. This also resulted in more communication 
APIs as the communication APIs were different. The above two changes 
fixes exactly that so I'm surprised you have no strong opinion on it.


At this point I have to ask what the problem you are trying to solve is? 
What is wrong with the current spec as is? I.e. rather than talking 
about various proposals, maybe we need to align the goals first as we 
might be talking past each other.

/ Jonas