Re: [w3c/manifest] Clarify ServiceWorkerRegistrationObject’s purpose (#800)

@aarongustafson 
> On the shared SW issue, my opposition was more to having one app within another (e..g., one with a scope of `/` and another with a scope of `/inner-app`) wherein URL-based disambiguation from within the SW might make updating the corresponding app icon more difficult.

Yeah... I don't like that story either but it's very hard to avoid. A store listing can simply prevent you from listing two apps that are nested inside one another. But a browser can't know about the other manifest. We've talked (on Chrome) about simply preventing the user from installing either an app scoped inside another already-installed app, or scoped outside an already-installed app. But we can't error either of those apps without seeing the other manifest.

Basically, not something we explicitly want to support, but not a condition we can detect either.

@christianliebel 
> we can’t replicate all possible Service Worker configurations in the manifest, which might break the requirement

What requirement?

> Also, as there can be more than one service worker script under a manifest scope, shouldn’t serviceworker actually take a list of registrations?

I similarly don't really think we should be supporting multiple SWs per app. Ideally, we would have a 1:1 mapping from apps to SWs.

The reason multiple SWs per app is bad, well there are two configurations:

1. Non-nested SWs that cover different parts of the app. This isn't really supported at all today, since there is an effective (non-standard) requirement that the entire app scope be covered by a SW. If multiple non-nested SWs cover parts of the app scope, that implies the root scope isn't covered by any SW. So let's avoid this case.
2. One major SW covering the whole app scope, and then other nested SWs covering smaller parts of the scope. This technically works, but it's problematic, since the app may behave differently depending on which SWs are registered and in what order. For example, if the outer SW is registered first, its fetch handler may prevent the pages on the inner SW from registering themselves, unless it is carefully written. Even if it's written carefully, the app may behave brokenly when offline if the outer SW is registered (which is a requirement of installation) but the inner SW is not (which would not be a requirement).

If large sites require this, we could consider it later, but the initial version of `service_worker` should be limited to one SW, IMO.

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