[whatwg] Workers feedback
jonas at sicking.cc
Thu Aug 7 11:53:15 PDT 2008
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.
More information about the whatwg