- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 20 Jul 2011 16:33:45 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-script-coord@w3.org
On Wed, Jul 20, 2011 at 3:03 PM, Ian Hickson <ian@hixie.ch> wrote: > > Dedicated workers and shared workers have a global scope called > WorkerGlobalScope. However, dedicated workers also implement > DedicatedWorkerGlobalScope; shared workers also implement > SharedWorkerGlobalScope. In the prose, to avoid having really awkward > phrasing, I refer to these three interfaces by those names; for example, I > talk about the global scope being a SharedWorkerGlobalScope object, or > creating a new SharedWorkerGlobalScope object. > > Currently I do this by having DedicatedWorkerGlobalScope and > SharedWorkerGlobalScope be marked [Supplemental, NoInterfaceObject] and > having them inherit from WorkerGlobalScope, so that they appear to just be > simple WorkerGlobalScope objects to scripts. As I understand it, the workers spec tries to create two different interfaces named WorkerGlobalScope. One that is available in dedicated workers, and one that is available in shared workers. Is this correct? If so, I think this is a bad idea. No other interface that I can think of has this sort of "dynamic" behavior depending on which global scope it is available in. For example an Array has the same API no matter what global it's gotten off of. There's also the problem that script that run either in a shared worker or a dedicated worker will have to deal with different WorkerGlobalScope interfaces. Ultimately I don't see what problem you're trying to solve, but I can see potential problems due to having a construct not used anywhere else. I think what we should do is to simply remove the "[Supplemental, NoInterfaceObject]" from DedicatedWorkerGlobalScope and SharedWorkerGlobalScope. / Jonas
Received on Wednesday, 20 July 2011 23:34:51 UTC