Re: [manifest] shouldn't the default scope be bounded? (#332)

Hi Paul,
> 1) I am unclear of the relationship between this and the SW scope,

This was discussed at some length in #114. The scope of the app is independent of the scope of a Service Worker, you should be able to install an app without requiring a Service Worker. The maximum scope of both an app and a Service Worker is the root of the origin, but a Service Worker may register to handle only a part of the scope of the app and vice-versa. It's possible to register multiple Service Workers for a single app.

The scope defined in the manifest is "navigation scope", it determines whether a navigation should be carried out in a browsing context or in an application context with a particular manifest applied, i.e. whether the navigation should be handled by a browser tab or an app (e.g. in a standalone display mode). Conversely the scope of a Service Worker can be used to determine whether an HTTP request is handled by the network or from a cache for example, but this is orthogonal to browsing context/application context and display mode.

Do you have any proposals of how to clarify this in the spec?

> 2) If SW has a scope then a 2nd scope adds a huge amount of confusion.

What do you think is confusing? If they had to have the same scope that could be very limiting. In particular I feel it's important that an app is not forced to register a Service Worker in order to register to handle a URL scope in a particular display mode.

I suspect that Google has a more Service Worker centric view on what apps are, but currently the direction of the spec is that a manifest identifies an app, and a Service Worker is an optional feature of an app (there are already many uses of the manifest which don't specify a Service Worker). Do you have an alternative proposal? We are discussing integration between the manifest and Service Workers in #161.

> Also deeplinking, the section in the spec makes no sense. Is there a plan for it to be expanded? I ask because Deep linking on Android has a very specific configuration, and I would expect to see some configuration of ownership of multiple paths, protocols etc (potentialy via a scope).

Can you expand on this? Which part doesn't make sense? What do you mean by "configuration of ownership of multiple paths, protocols etc"? There have been various proposals for how to define scope in the manifest including a list of URL prefixes, whitelists, blacklists and a "stay_in_app" property for cross-origin navigations which should stay in the app if they originated in the app. The current spec is quite simplistic, do you have a proposal for something more complex?

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/332#issuecomment-83990522