[whatwg] Workers feedback

[Jonas Sicking]

Ian Hickson wrote:
> On Wed, 6 Aug 2008, Aaron Boodman wrote:
>> I am opposed to the utils object. I don't see any precedent for this 
>> anywhere, and it just feels ugly to me. I liked it the way you had it 
>> before, with these APIs in a shared base interface.
> 
> Ok. I don't have an opinion on this. Jonas?
> 
> In the absence of any arguments either way, my default would be put it all 
> on the global object; clashes are manageable, the Window object does it 
> that way, and there are enough things that we kinda want to put on the 
> global scope anyway (the core worker stuff) that it's not a clear that the 
> gain is huge.

I don't feel very strongly about this right now. It's something we 
started debating at mozilla and I think we'll debate it a bit more 
before coming to a conclusion. I'm fine with putting it in the global 
scope for now. Sorry, i didn't mean to ask for an immediate action on 
this yet.

>> That's also one reason why I like having a separate Worker object and 
>> having the two-step process of creating the worker, then sending it a 
>> message. It means that creating a new channel to a worker is always the 
>> same.
> 
> It seems that designing the API to add extra steps is a bad thing 
> generally speaking. :-)

Though in the vast majority of cases only the first step is needed. A 
second step is only needed in the very complex use cases of:

* Having sibling workers talk directly to each other.
* Having a worker talk directly to a frame from a different origin.
* Having a worker shared across different instances of the app.

>> I think that 'load', 'error', and 'unload' could go on the worker. As 
>> far as I can tell, the only thing 'load' and 'error' are used for is 
>> telling the creator of a worker that the worker loaded or failed to 
>> load. In that case, it seems wrong to throw them on MessagePort, since 
>> MessagePorts are also used for many other things.
>>
>> I also still think that Workers could have their own sendMessage. The 
>> messages sent to this would be delivered to the worker as 'message' 
>> events targeted at WorkerGlobalObject (eliminating the need for 
>> onconnect?). This would make Workers and postMessage very similar to 
>> Window and postMessage, which seems nice to me.
> 
> How's this for a compromise:
> 
> We make the createWorker() methods return a Worker object, but the Worker 
> object _inherits_ from MessagePort. So effectively it is a port, but we 
> can move the onload and onerror stuff to the Worker object instead of 
> having them on all MessagePorts.
> 
> Would that work for you?

I thought about that, but what happens if you pass such an object to 
postMessage? Throws an exception? Only the parts of the API that is a 
MessagePort dies?

One solution I thought about is to have a base interface such as:

interface MessagePort {
   void postMessage(...);
   attribute EventListener onmessage;
   ...
}

Then have

interface Worker : MessagePort {
    bool isShared();
    <worker specific stuff>
}

interface PipePort : MessagePort {
    attribute Window ownerWindow;
    <Pipe specific stuff>
}


And then make the APIs that we want to allow passing around pipe-ends 
take a PipePort object.

The result is basically that workers are separate objects from what's 
returned for (new MessagePipe()).port1, but they share some API.

>>>> - Should import() accept an array of URLs, so that the UA can fetch 
>>>> them in parallel if it has the ability to do that?
>>> We could do that if you like. Is it needed?
>> With the connection limits being upped in all the browsers, I think this 
>> would be a good thing to have from the beginning.
> 
> Fair enough. Should they be run in whatever order they load in or should 
> they be run in the order given on the aguments?

Yes. Another thing is that this function should probably return void and 
always throw if something goes wrong. I doubt that having the server 
return a 404 is expected enough that just returning 'false' will keep 
the program executing fine.

/ Jonas