Re: [w3c/ServiceWorker] Service Workers are too hard to clean-up (Issue #1695)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1695)

I understand your point about detecting ServiceWorker deletion.  I initially thought it might occur at similar times to an update, but after reviewing the specifications, it seems that is not the case.

Service Worker updates typically happen when:

- A page within the ServiceWorker's scope is accessed.
- Push notifications or other events are received.
- `register()` or `update()` methods are explicitly called.

These update triggers do not align with the scenario you are describing, which seems to be about automatically deleting a Service Worker after a period of disuse.  I do not believe there is an existing mechanism to trigger such a deletion based on inactivity.

Looking at recent comments, it appears the goal is not necessarily a complete deletion of the Service Worker after a period of disuse, but rather for it to become inactive or disabled.  This makes more sense given the current Service Worker lifecycle.

Regarding your objective, the ServiceWorker Static Routing API (specifically the `RouterTimeCondition` or `RouterIfDate`, as mentioned in https://github.com/WICG/service-worker-static-routing-api/blob/main/final-form.md and discussed in https://github.com/w3c/ServiceWorker/issues/1373 and https://jakearchibald.com/2019/service-worker-declarative-router/#routerifdate) seems particularly relevant.  However, it is important to note that the `RouterTimeCondition` is still under discussion and is not yet a implemented part of the ServiceWorker specification.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1695#issuecomment-2961325288
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1695/2961325288@github.com>