Re: [REFERRER] Where does "Determine request’s Referrer" get its URL from?

(Jungkee, Jake, there's some feedback on the service workers
specification below.)

On Thu, Jul 31, 2014 at 5:14 PM, Ian Hickson <> wrote:
> The Client object here doesn't seem to have much to do with the "client"
> concept in the fetch specification. One is a JS Object in the
> ServiceWorker scope. The other is a JS Lexical Environment with a null
> outer environment reference.

What they are meant to refer to is equivalent in the abstract.

> What I was asking is why does fetch use a global environment as one of the
> concepts it tracks, instead of, say, an event loop, a script settings
> object, or a global object.

A global object or something on the same level is what I'm looking
for. I did not realize a global environment would be much different.
But I can see now how a global environment is very JavaScript-specific
whereas a global object could work across languages.

Should I reference then?
And then specifications that hook, can talk about client being a
Window, WorkerGlobalScope, DedicatedWorkerGlobalScope,
SharedWorkerGlobalScope, or ServiceWorkerGlobalScope...

> BTW, the current logic for MessagePorts in the ServiceWorker spec is
> incomplete. There's only one port, as far as I can tell. It's entirely
> defined in a non-normative note (though that note has "must"s). That note
> is rather ambiguous (e.g. what task is used to redispatch the events? Is
> the data in the event maintained? How is the event created?) What does
> postMessage() on Client do? (It has no normative description.) Why are we
> posting messages to the Window object? Or the SharedWorkerGlobalScope
> object? How would messages be posted back? I honestly can't tell, from
> reading the bit about messages, where the Client object would be visible
> from (inside the ServiceWorker, or inside the environment that caused the
> fetch?). The IDL suggests one answer, but the prose suggests the opposite.
> I'm not really clear on what these communication mechanisms are for,
> exactly, so it's hard to evaluate if they make sense in general.


Received on Friday, 1 August 2014 04:57:19 UTC