[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

Alexey Proskuryakov wrote:
> 
> Nov 5, 2008, ? 11:06 PM, Aaron Boodman ???????(?):
> 
>> Jonas, Hixie, and I talked about this yesterday on IRC (logs start
>> here: http://krijnhoetmer.nl/irc-logs/whatwg/20081104#l-575 and go
>> into the next day).
> <...>
>> * Remove startConversation() from the Worker interface
>> * Remove the port property from the SharedWorker interface and give it
>> a postMessage and onmessage just like dedicated workers have.
>> * Leave the interfaces for the insides of the workers as they are now
> 
> 
> Something that seems missing from these discussions is how the API 
> changes affect semantics of worker behavior, which makes it hard to 
> compare proposals. For example, having some port singled out as an 
> attribute of Worker (or as an implicit hidden attribute, used by methods 
> defined on Worker itself) sorta implies that closing it should close 
> other ports and dispose of the worker global scope soon.

No, that is not how the spec currently works. Currently if you call 
close() on the port property of a shared worker that only closes *that* 
port. This does not affect other communication channels with the worker, 
including channels held by the same script. So in other words, if I do 
(in the current proposal):

w = new SharedWorker("foo.js", "name");
ch = new MessageChannel();
otherPort = ch.port1;
w.port.postMessage("here's the other port", ch.port2);
w.port.close();

I can still use otherPort to communicate with w. I'll just be 
communicating with whatever messagehandler the worker installed on the 
port that was delivered along with the "here's the other port" message.

> Similarly, 
> having separate interfaces for Worker and SharedWorker implies that 
> there is some fundamental difference in their behavior - a difference 
> that eludes me so far.

A shared worker is shared between all scripts on a single site[*] that 
instantiates a worker with the same name. I.e. where the second argument 
to the constructor is the same. (Don't remember what happens if the 
second argument is the same as an existing worker, but the first is not, 
check with the spec).

This means that two pages on the same site can share whatever resources 
the worker is using, such as a connection to a serverside database, or a 
local cache of calculated results.

> It would seem that we could make better progress if we had a list of 
> requirements that we want to have fulfilled (e.g., should it be possible 
> to easily manage worker lifetime manually by closing a dedicated port? 
> or should workers strive to remain available for as long as any client 
> has an open port, which helps write reliable code?).

We have discussed a lot of use cases in the past. I'm not sure if we've 
saved that anywhere though :(

/ Jonas

Received on Wednesday, 5 November 2008 15:18:32 UTC