W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: Vestiges of [Supplemental]

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 20 Jul 2011 16:33:45 -0700
Message-ID: <CA+c2ei8Q7oBJLcWWEb6KBp1YaqzvdZPAdKfLavR5mNif+yxqUA@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC