- From: Alvaro <notifications@github.com>
- Date: Mon, 03 Jun 2024 10:18:19 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1720/2145739272@github.com>
> I see what you're trying to accomplish, but here are my thoughts (hopefully without offending). Your idea creates the potential of a schism where some clients are operating on the latest service worker, while others are not, which creates a potentially very complex inconsistent environment that could corrupt the shared domain's intent behind updating their service worker, upending the basic premise behind who controls the service worker and forcing domain admins to accommodate potentially many historical versions of serviceworkers if they change frequently enough. It's doubtful the client will be smart enough to know what's the best decision, particularly if the serviceworker update addresses a critical security flaw/bug. > > I believe the existing approach of scoping serviceworkers to domains where all clients update in sync represents the more encapsulated approach, and much easier to digest conceptually. In other words, if your use case is to control the serviceworker version, then take control by owning a specific domain for the relevant clients, rather than trying to make a shared domain fit, unintuitively inverting control of the updates to the client. > > I've been an advocate of disabling serviceworker updates entirely in scenarios where the serviceworker cannot change (IPFS), but you're still looking for updateability, so it's a different use case. I understand your worries, and think out of sync will always be an issue, these might be due to networking, caching or from any number of reasons. the proposal aims to preserve the correct state of the web application as defined by the author (as it should be), while also having the flexibility to fallback into the default state, I believe this is a really well balanced solution that could appease fears from both sides. offcourse being backwards compatible this proposal allows you to chose the option to verify, if not then there will be no side effect. Understanding the proposal as simple optional step that would bring peace of mind and assurance for my self, and others developers is key. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1720#issuecomment-2145739272 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/1720/2145739272@github.com>
Received on Monday, 3 June 2024 17:18:23 UTC