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
