[whatwg] Workers feedback

[Chris Prince]

>> 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.
>
> The language should be done via an HTTP Content-Type. isContent can be
> done using data: URLs instead, if this is really needed. If we want to do
> something with a different lifetime I think we want to do it with a much
> clearer API entry point than an option burried in an argument.
>
> So I'm not really convinced about this. I would be interested in other
> viewpoints, though.

I think you are missing the point.  I'll try to rephrase it:

It is short-sighted to expect you can fully spec something as large as
workers.  This is a significant new concept, and we are only
scratching the surface.

So why back ourselves into a corner?  Let's be smart about the API
design, and allow for future flexibility.

I don't see any downsides to the approach outlined above.  If you have
something specific in mind, please let us know.