[whatwg] Combining the DedicatedWorker and SharedWorker interfaces

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.  
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.

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?).

I really don't think that the desire to save one line in a 500-line  
program should affect the design too much. Convenience methods can be  
added later, but over-engineered parts cannot be removed later. And at  
this point, I believe that  we are mostly speculating about use cases  
(probably except for Google Gears folks, who are shipping a similar  
API, and get developer feedback already).

- WBR, Alexey Proskuryakov

Received on Wednesday, 5 November 2008 13:23:50 UTC