>> - Would it be too weird to have createWorker overloaded to take an >> optional name parameter? This would make the behavior similar to >> window.open(), which either opens a new window or reuses an existing >> window with the same name. > > People seem to dislike overloading in general, but I don't mind. Anyone > against this?
First, let me apologize for not jumping into this thread earlier. As I was the one who designed workers, and have been iterating on the design for nearly two years now (!), I really need to start sharing my thoughts on this list, instead of just the Gears lists. I'll try to write up some more detailed comments later, but for the question above about a 'name' parameter and overoading: 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.