Re: [w3c/ServiceWorker] Sort out settings object for service worker module scripts (#1013)

@Domenic, @annevk,

I've been thinking about the environment settings object for service workers. Currently we create a settings object for a service worker whenever [Run Service Worker](https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm) needs a cold start. So, it's basically 1:1:1 to the realm and the global object as for other environments. However, having thought about it more, I think it should rather be bound to the service worker's lifetime instead of the realm and global object's lifetime. It seems most of the settings object's fields can be (or need to be) maintained across multiple global objects' creations and terminations. Moreover, _fetching a * worker script_ requires a settings object, which isn't what service worker's [Update](https://w3c.github.io/ServiceWorker/#update-algorithm) algorithm strictly follows at the moment. (Update step 7 now passes a to-be-created environment settings object to _fetch a * worker script_.)

That considered, I propose we create an environment settings object for a service worker in [Update](https://w3c.github.io/ServiceWorker/#update-algorithm) algorithm before invoking _fetch a * worker script_. This settings object is associated with the service worker's script during _fetch a * worker script_ execution. And [Run Service Worker](https://w3c.github.io/ServiceWorker/#run-service-worker-algorithm) algorithm later uses this service worker's script's settings object to run the script with additional set up steps that associate the settings object with the created realm and the global object.

One tricky part is [fetch a module worker script graph](https://html.spec.whatwg.org/#fetch-a-module-worker-script-tree) > .. > [create a module script](https://html.spec.whatwg.org/#creating-a-module-script) > [ParseModule()](https://tc39.github.io/ecma262/#sec-parsemodule) requires a realm while service worker's Update doesn't create a realm. In my understanding, the only reason that the realm is passed is to set the created script's module record's [[Realm]] internal slot, right? If so, can I set/pass the environment settings object's Realm to undefined at this stage? And later override the value to the actual realm created in Run Service Worker?

To sum, I propose we redefine the lifetime of service worker's environment settings object to satisfies the processing model. It would look something like:

**Update**
- Create an environment settings object with its realm initialized to undefined.
  - Realm execution context returns null.
  - Module map is initial empty map.
  - Create an event loop [1]
- _Fetch a * worker script_ with the created settings object

**Run Service Worker**
- Create a parallel context
- Invoke [InitializeHostDefinedRealm()](https://tc39.github.io/ecma262/#sec-initializehostdefinedrealm) - i.e. Create a realm
- Create a global object
- Set up the settings object with service worker's script's settings object and the created realm
  - Set script's module record's [[Realm]] to the given realm
  - Set realm's [[HostDefined]] field to the given settings object

[1] If it makes sense to create the event loop in Update and use it until the registration is cleared, we don't even have to back up the tasks to registration's task queue in [Terminate Service Worker](https://w3c.github.io/ServiceWorker/#terminate-service-worker-algorithm). Does it make sense?

WDYT?

-- 
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/issues/1013#issuecomment-286343478