[whatwg] Workers feedback

[Jonas Sicking]

Aaron Boodman wrote:
> 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.

Hixie asked me on IRC why I didn't like the MessagePort solution. So 
here is a list of a few reasons:

I prefer that the createWorker function returns an actual Worker object. 
I think that is what you would expect from an API with such a name. 
Otherwise we should call it something like 
createAWorkerAndReturnAMessagePort. We shouldn't trick people into 
thinking that they have a worker when they really have a MessagePort, 
even if the two APIs happen to mostly align. One way to fix this and 
still keep MessagePorts would be to return a Worker object that has a 
.port property, but that has other problems, see below.

To add to the above point, while the MessagePort API currently aligns 
with the proposed Worker API, this seems likely to change in the future, 
for example to test if a worker is shared between multiple frames.

I in general am not a big fan of the MessagePort API, the whole cloning 
and dying thing is really ugly. I don't think there is much we can do 
about that, but because of it I think we should only use the API when 
it's strictly needed, which seems to be only in fairly complex usecases. 
I am aware that returning a MessagePort basically means that you write 
your code the same way in the trivial cases, but I dislike designing a 
complex API and telling the users "don't pay attention to the full API 
of the object you are using, just think of it as something else and 
it'll work fine".

Exposing a MessagePort as a permanent property, like the global 'port' 
property, has the downside that that object can potentially die if the 
MessagePort is ever passed through postMessage somewhere. This leaves 
the user with a permanent property containing a dead useless object. Not 
exposing it as a permanent property forces things like the onconnect 
event and returning a MessagePort from createWorker.

> On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince <cprince at google.com> wrote:
>> My current thinking is that the best API design for createWorker() is:
>>   MessagePort createWorker(worker_body, [WorkerOptions])
>>
>> The reason: workers are a powerful concept, and it's very likely we'll
>> want to extend them over time.
>>
>> The 'name' option is just one such case.  Here are a few others:
>>
>>  - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm')
>>  - 'isContent' to pass a string or Blob instead of a url
>>  - 'lifetime' for running beyond the lifetime of a page
>>  - etc.
>>
>> I'd say other options are likely to be just as 'important' as name, so
>> I wouldn't special-case that parameter.  A 'WorkerOptions' parameter
>> supports naming, but future expansion as well.
> 
> FWIW, Chris's suggestion is also fine with me. In general, I like
> these options objects since they are easily extensible.

I do sort of prefer the idea of keeping the "give me a worker that is 
potentially shared with other windows" API separate. In fact I think we 
should call it createSharedWorker or some such. But allowing optional 
arguments at the end seems like a good idea. Not sure if that requires 
specific action right now or not though.

/ Jonas