Re: [w3c/manifest] Add a unique identifier for a PWA (#586)

> @philloooo wrote:
> 
> > Good point that using manifest_url is more linkable. Can you give an example use case that having the ID being a resolvable URL is needed/better?
> 
> I have a few key use cases in mind:
> 
> 1. **Updates** - If user agents can index web apps by their manifest URL, all they need to do to get the latest version of the manifest is to fetch that URL. This would help fill a key hole in the manifest specification regarding how to update a manifest, where the alternative would be much more complex. This is particularly useful where the web runtime is separate from the operating system (i.e. not something like Chrome OS or Firefox OS), because the operating system can fetch updates itself (e.g. to update icons on an app launcher). If the manifest URL does need to change for some reason, an HTTP redirect can tell the user agent to replace the current app rather than install a new one.

Updates are definitely easiest in the manifest_url=global_id case. They are still possible using other schemes, but less nice.

> 2. **Remote installation**
>    
>    1. **App stores** - We don't really talk about the fact that the way Microsoft uses manifests in the Microsoft Store is not compliant with the specification, because you can only really install an app from a document belonging to the app itself. Having the app ID resolve to its manifest is a step towards allowing installation of web apps from app stores/directories, if all you need to link to and install an app is its manifest URL. (See also: #668).

I would expect that there would have to be a little more of a verification step here, either by the user agent or(and) by the store, to make sure that the document at start_url has a manifest link that matches the manifest_url. This step would probably be similar with other id schemes as well.

>    2. **App provisioning** - Similarly, it could be possible in future to remotely provision a web app to a collection of user agents (e.g. a classroom full of Chromebooks), just by sending the manifest URL.

This functionality, in theory, already exists in Chromium, as you can policy-install apps. It definitely has more hoops to jump through (loads the given URL, looks for manifest link, then uses that), but is possible.

>    3. **Digital signage** - Similar to the above, I'm currently working on a use case in digital signage where I'd like to be able to remotely install a web app to a kiosk runtime, which doesn't have its own user agent UI to install a web app. The kiosk runtime runs a single web app at a time full screen. It's quite common in digital signage to remotely provision APKs to an Android runtime, but the same is not currently possible with web apps.

Do you mind expanding on this? Would web packaging solve this use case? I could see us sending a web package to the kiosk as an option here too. I can also see the above policy-install functionality work too (more round-about, yes, but it works)

> 3. **Link relations** - There was an [example](https://github.com/WICG/pwa-url-handler/blob/master/explainer.md#web-app-to-origin-association) linked above where one web app manifest might want to refer to another web app manifest, to denote some kind of relationship between to the two apps. By using a simple web URL as an identifier it's possible to use link relations which describe all kinds of relationships between apps. Having the identifier resolve to metadata about the app is even more convenient (e.g. in the linked use case, for building the UI for a permissions prompt using the app's icon and title).

I find this interesting! This is a nice feature. I think this is the first case here where it more on the impossible-side (or too-klunky-to-be-workable) for other schemes vs this scheme.

> 
> > Re: manifest_url versioning, If I understand it correctly, doing 301 redirect, or add an "import" syntax means that: the document will always still reference the original manifest, so user agents will keep the same previous ID for the app, and always do another round trip to fetch the latest content?
> 
> As described above, if a user agent receives a redirect response when fetching a manifest URL, it can choose to replace the app (including its new ID), rather than install the new manifest as a separate application. That way the redirect only has to happen once on the user agent (but the server would need to maintain redirects for old manifest URLs for user agents which haven't updated yet).
> 
> The import approach could also work and might be more CDN friendly, but has the downside of always requiring an additional round trip, as you say.
> 
> There are obviously also other ways of telling a user agent that a manifest has changed which don't involve changing its URL, or re-fetching the whole manifest, (e.g. `ETag` or `Last-Modified` headers with less aggressive caching).
> 
> > Note: we also still have the use case of specifying manifest as data url.
> 
> That would still work, a data URL can be used as an ID (I've done this in the past for storing icons). Obviously the limitation of choosing to use a data URL for a manifest is that if the manifest content changes, the manifest URL also changes and it becomes a new web app. But to me that feels like a reasonable compromise for such an edge case.

We could also do something weird like - say that the id = scope + "/manifest.webmanifest".  Probably a bad idea. Any ideas about how to allow these to update & maybe migrate to a manifest file?




I think the main other issue with manifest_url = global_id is that you are STUCK with the url - if that was on a CDN, and that CDN goes out of business... or goes down, etc. You are stuck forever. Probably would mean, if we choose this option, we encourage devs to make sure they control the URL & 301 (is there a dns redirect you can do?) or something to a CDN if they need to. But I could see this biting people in the butt.

-- 
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/586#issuecomment-773518907