[whatwg] Workers comments

[Jonas Sicking]

So having read through the workers spec I have a number of fairly large 
concerns.

The overall concern is that I think the spec is unnecessarily
complicated. I'll comment in detail below on specific features. An
overall requirement for mozilla is that we are very selective about
which features are exposed on the thread. For example exposing a full
navigator or window object is a huge amount of work. This doesn't mean
that it shouldn't be done, but there needs to be very good reasons when
exposing things.

So the first comment is the 'window' and 'self' properties. I don't see
a reason for these. I got a comment that they were there for easier
porting of code from the main window to a worker context. However just
having access to the window object is unlikely to help much. People
don't use the window object, they use properties and functions off of
it, such as window.location, window.name, window.document etc. So
without also adding these properties too I think it's unlikely that many
more scripts will run. Further I think having a property called 'window'
that doesn't return a true window object, with everything that goes with
it, is going to be a big source of confusion for developers.

On the subject of window. I think the fact that the global scope
interface is named something with 'Window' is very confusing for anyone
reading the spec. While I agree that there is some amount of association
between the global scope and the window, I think there is a much
stronger association between window and the properties that live on it,
such as window.location, window.document, window.frames, window.scrollX, 
etc.

Additionally I am worried that sharing interfaces between the global 
scope object for browser contexts, and the global scope object for 
workers is going to lead to unnecessary feature creep with argument such 
as "the object is available in the browsing context, so why not make it 
available in the worker context". I much rather want arguments like 
"this feature is needed in thread contexts because of reason X and use 
case Y". This is due to the fact that making threadsafe


What is the use cases for the onconnect and onunload properties?
'onconnect' doesn't seem to add anything beyond simply leaving the code
outside any function. I.e. doing

function foo() { ... }
function bar() { ... }
function onconnect() { <code here> }

seems the same as

function foo() { ... }
function bar() { ... }
<code here>


The fact that the only way to communicate between workers and the main 
browser context is through MessagePorts seems unnecessarily complex as 
well as differing from how windows communicates using postMessage. I 
think MessagePorts are a fine concept, but I don't think they should be 
mandatory as I think in many cases they are more complicated than 
needed. The whole concept of entangled message ports that clone and die 
when you pass them around is something that I don't think we should 
force upon developers unless absolutely needed. In the current draft I 
can't even see how to reach the message port object inside the worker, 
though that might be a temporary oversight. But it does indicate that 
the level of complexity for communication is non-trivial.

A better model seems to be reusing what we do for window objects. Simply 
make createWorker return a Worker object that has a sole .postMessage 
property, and make it possible to pass a Worker object through 
postMessage. We would also have to expose some way to send messages to 
the main browsing context, either through a separate postMessageToWindow 
function inside the worker context, or through a Worker object 
representing the main browser context. This doesn't stop us from adding 
support for MessagePorts as well, but it allows sites not to mess with 
them unless needed.


In general I feel like the current draft is very far from the three 
existing drafted APIs; the old google gears API, the new google gears 
API and the API from mozilla. I would much rather start from any one of 
those and make changes as needed based on use cases and experience from 
those implementations. This should help both with ease of 
implementation, as well as ease of porting code written for the existing 
gears API.

/ Jonas