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
