Writing ServiceWorker-Using Specifications

[jungkees]

For the other specs (currently Background Synchronization, Push API, Task Scheduler) that extend Service Workers, we need to provide a guide in the spec. Here's a sketch of the section: https://gist.github.com/jungkees/3154398b8deee7c70139

Please comment on it.
/cc @slightlyoff @jakearchibald @sicking @annevk

[jungkees]

Based on the discussion in https://gist.github.com/jungkees/3154398b8deee7c70139, navigator.serviceWorker.ready has been changed to resolve only with an active worker: 1465d26

/cc @coonsta @nikhilm @inexorabletash @michael-nordman

[jakearchibald]

We should update this for the new registration model

[jakearchibald]

Here's a rough sketch:

If a new web platform feature fires events within a ServiceWorker, or requires user permissions that last beyond the length of the page, it should extend ServiceWorkerRegistration to add an interface containing required methods and state.

serviceWorkerRegistration.apiSpace.method(_list of arguments_) must run these steps:

1. Let p be a newly-created promise.
2. Return p.
3. Run these steps asynchronously:
   1. If registration.activeWorker is null, then:
      1. Reject p with an "InvalidStateError" exception.
      2. Abort these steps.
   2. Do the necessary steps specific to the API.

It's down to the API to decide whether to resolve/reject the promise. The API should be able to store state along with the registration (permissions granted, registrations etc).

Unregistration of the serviceworker will remove all state & registrations associated with the API (do we need to provide a hook here?).

Events fired to a ServiceWorker must only be targeted at the active worker in the associated registration.

ServiceWorker upgrades do not affect state stored along with the registration.

Existing APIs (defined outside of ServiceWorkerRegistration) that may wish to optionally fire events in a ServiceWorker should take a ServiceWorkerRegistration as an argument.

[jungkees]

6bcb33b Closing.