Re: [w3c/ServiceWorker] Fix arguments to "fetch a classic worker script" (#1012)

jungkees commented on this pull request.



>          <dl>
         <dt><em>"<code>classic</code>"</em></dt>
-        <dd><p><a>Fetch a classic worker script</a> given <var>job</var>’s <a lt="URL serializer">serialized</a> <a href="#dfn-job-script-url">script url</a>, <var>job</var>’s <a href="#dfn-job-client">client</a>, and "<code>serviceworker</code>".</p></dd>
+        <dd><p><a>Fetch a classic worker script</a> given <var>job</var>’s <a lt="URL serializer">serialized</a> <a href="#dfn-job-script-url">script url</a>, <var>job</var>’s <a href="#dfn-job-client">client</a>, "<code>serviceworker</code>", and the to-be-created <a>environment settings object</a> for this service worker.</p></dd>

I see. Having looked at those _fetch/run worker script_ algorithms, in the case of module script, the parsing is all done in _creating a module script_ which is called during the fetching phase. The problem we have with SW script execution model is that fetching and running execute in separate places with a different lifecycle from that of other workers. I don't think I fully understand the module script execution model, but would it make sense to do something like:
- SW: Create a (concrete but initialized with minimal things) environment settings object before [Update](https://w3c.github.io/ServiceWorker/#update-algorithm) step 7 and give it to _fetch a module worker script graph_.
- HTML: This above steps compose the module map as expected and it's stored in the _script_ asynchronously returned as a result of the fetch.
- SW: That _script_ is stored in the [service worker](https://w3c.github.io/ServiceWorker/#dfn-service-worker)'s [script resource](https://w3c.github.io/ServiceWorker/#dfn-script-resource) slot.
- SW: When Run Service Worker is invoked, it's given the service worker and the _script_ in the script resource slot. In this algorithm, when a new environment settings object is created, copy necessary states from the given _script_'s settings object. Or even just reuse this _script_'s settings object as-is to run the script? (Not sure this scenario makes sense. Can a realm created during the fetching phase can be reused in all the subsequent Run Service Worker script executions?)

Anyway, agreed that we'd better fix it in a separate issue. I'll merge this to be aligned with HTML changes in the meantime.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1012