[whatwg] Workers comments

[Aaron Boodman]

On Mon, Aug 4, 2008 at 8:24 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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.

I don't see anything about a 'navigator' object except this comment:

May need to define a browser sniffing API (like window.navigator).

That doesn't imply to me that it will be the entire navigator object,
just something having similar capabilities wrt browser sniffing.

Similarly, the only thing that the spec says should be available from
Window are the things listed in these two interfaces:

http://www.whatwg.org/specs/web-workers/current-work/#the-windowworker
http://www.whatwg.org/specs/web-apps/current-work/#window

This is a very small subset of Window.

> So the first comment is the 'window' and 'self' properties.

I agree, these seem unnecessary.

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

I agree with this. I think the global object in a worker should be
called something different, such as WorkerGlobal or WorkerContext.

I don't think we should pay too much attention to trying to make
existing code compatible with this environment, as that seems
hopeless.

However, I do feel that in the cases where an existing interface works
nicely for its intended purpose, there's no point reinventing it. Less
"brain print", as a coworker likes to say.

So for example, I would be for moving over a subset of the navigator
and location objects as-is (these seem to work well), but against
moving over the document.cookie "interface" (it works poorly).

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

I don't think having a common base interface in the spec is going to
make this kind of feature creep any more or less likely. It just seems
natural that if functionality is available in both workers and the
main browsing context, it should work the same way.

> 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

I believe that onconnect is meant to be how a worker gets the
MessagePort object from people who are trying to talk to it.

Hixie, it occurs to me that it might be helpful for everyone if you
could add some code samples for how applications would use this API to
the top. It's easier to grok what the point is at a glance, and allows
people to think about the API proposal holistically instead of trying
to piece it together from the algorithms.

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

I can get behind simplifying the API. However, the "simple" I would go
for would be to just allow workers to talk to their creator. No
passing workers (or ports) around at all.

If we decide to allow workers to talk directly to other people than
their creator, then I think something like MessagePorts is a better
approach than passing workers around. The advantage of MessagePorts is
that it works with iframes too.


- a