Re: [w3c/push-api] Expose pushManager on Navigator (PR #368)

I was looking at tackling this but ran into #384. Because #360 actually describes something that I think we can use. It suggests that a "window push subscription" is 1:1 with a push subscription for a service worker registration whose scope is `/` (on the same origin).

I think we should just create a service worker registration for that scope when none exists and bypass the active worker check (which seems to be there mainly for consistency).

An issue that we run into, but the existing specification also runs into, is this line in the Service Workers specification:

> A [service worker registration](https://www.w3.org/TR/service-workers/#dfn-service-worker-registration) of an identical [scope url](https://www.w3.org/TR/service-workers/#dfn-scope-url) when one already exists in the user agent causes the existing [service worker registration](https://www.w3.org/TR/service-workers/#dfn-service-worker-registration) to be replaced.

But it seems to me it could just as well say that it's being updated in place (or that some state, such as the push subscription, is carried over).

This setup has these benefits:

1. Clarifies the lifetime by tying it to service worker registration lifetime. No need to integrate with Storage (though Service Workers needs to of course).
2. Creates interoperability with existing push subscriptions on scope `/`.
3. It is very simple. No need for more complicated ownership structures or anything. Only fairly modest changes to the `PushManager` class.

Thoughts?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/pull/368#issuecomment-2233366143
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/pull/368/c2233366143@github.com>

Received on Wednesday, 17 July 2024 13:45:22 UTC