- From: Brad Isbell <notifications@github.com>
- Date: Mon, 19 Feb 2024 15:41:58 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 19 February 2024 23:42:02 UTC
I think the root problem here is that scoping is backwards. A scope should be defined as the requests that a Service Worker should be allowed to handle, rather than where a Service Worker is allowed to run. For example, a developer should be able to register a Service Worker from a different origin that handles requests for that origin. Maybe that Service Worker knows how to speed up certain resources, or knows how to fetch them differently. But, the developer may want to limit that third-party service worker from accessing their API on behalf of the user. That's what scope should be for. If scope was flipped around, having multiple Service Workers would be no problem as there would not be conflicts for the same scope. The use cases presented here are about external libraries and services that use their own Service Workers. Well, if SomeAnalyticsService needs to register, it can be scoped to its origin by default, or the developer can change the scope if necessary. Either way, it won't affect the main scope of the site. Scope is backwards as implemented today. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/921#issuecomment-1953280883 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/921/1953280883@github.com>
Received on Monday, 19 February 2024 23:42:02 UTC