Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing ServiceWorker-Using Specifications #349

Closed
jungkees opened this issue Jun 30, 2014 · 4 comments

Comments

Projects
None yet
3 participants
@jungkees
Copy link
Collaborator

commented Jun 30, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 3, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2014

We should update this for the new registration model

@jakearchibald

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

commented Nov 20, 2014

6bcb33b Closing.

@jungkees jungkees closed this Nov 20, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.