- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Fri, 22 Apr 2016 16:45:49 -0700
- To: slightlyoff/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc:
- Message-ID: <slightlyoff/ServiceWorker/pull/889/r60816467@github.com>
> <dt><em>"<code>module</code>"</em></dt> > - <dd><p><a>Fetch a module script tree</a> given <var>job</var>’s <a>serialized</a> <a href="#dfn-job-script-url">script url</a>, "<code>omit</code>", "<code>serviceworker</code>", and <var>job</var>’s <a href="#dfn-job-client">client</a>.</p></dd> > + <dd><p><a>Fetch a module script tree</a> given <var>job</var>’s <a>serialized</a> <a href="#dfn-job-script-url">script url</a>, "<code>omit</code>", "<code>serviceworker</code>", and some settings object.</p></dd> > You can't start a worker until its global scope/settings object have been created; it doesn't really make sense. Why do you think it's necessary in this case? Currently service workers do: `fetch, create settings object, start`, while other workers do: `create settings object, fetch, start`. So in both cases start happens after creating a settings object, it's just the fetching that happens differently. The way the algorithms are currently written we don't create a settings object until after an update check has decided that a new script was indeed downloaded and we really need to start the worker. But yeah, it might actually be a lot clearer/easier to understand if we always create a settings object/global scope for the service worker before we initiate any kind of fetch/update check. If the update check fails we just throw the settings object away, and if the update check succeeded we can then reuse it to fire the install event at etc. Additionally at the end of a successful update check we can store the settings object's module map, similarly to how we currently store the workers script (and when we have to restart the same worker we can prepopulate the settings object's module map with that same module map). That would also address a couple of other places where the spec currently doesn't make sense around module type workers. Actually rewriting things like that would be a fairly major undertaking, but probably the best way to actually make this all make sense... > It sounds like there's a bug in the referrer handling though; filing an issue at whatwg/html would be much appreciated! Will do. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/slightlyoff/ServiceWorker/pull/889/files/9e6c421e7a040fa5d81b1476566343c268353f4d#r60816467
Received on Friday, 22 April 2016 23:46:16 UTC