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

@mgiuca wrote:
> Using a different manifest URL is the currently recommended and only viable way to provide localized manifest metadata.  So we have to support that, unless we want to block on #676 (properly supporting localization). 

That's not strictly correct. The specification also mentions that servers can use the "Accept-Language" header to provide the user with a manifest in their preferred language. It's perfectly valid for the same resource at the same URL to have different representations as a result of content negotiation like this, it doesn't make it a separate resource. An HTTP URL identifies the resource, not its representation.

Either way, I don't see this as a problem. If the user installs the French version of an app, they presumably want to continue using the French version of the app when the manifest is updated, either based on the default language preference set in the user agent or by manual selection via a query string. (I would argue this is "properly supporting localization" and as I understand it was an intentional design decision, but I will comment on the other issue about that.)

> Well. "Multiple manifests" is a bit hard to define (if a manifest changes its content or its URL, is that "multiple manifests"?).

As above, if the URL changes then yes. If the content changes but the URL remains the same then no. This works in either localisation case because either you're explicitly requesting a resource which is a manifest for a French app, or you're requesting a multi-lingual resource and asking for the French representation of it.

> The whole point of the ID is so that we know when "two web app manifests" represent two different apps versus two different versions of the same app.

I would argue the manifest URL can already provide this. The only compelling reason I've heard so far for adding an additional identifier URL is where people are using version URLs for manifests in a CDN. I have to be honest that this isn't a problem I've ever come across, but I know this is an approach that [Google recommends](https://cloud.google.com/cdn/docs/best-practices) so maybe it's more common and a harder problem than I realise.

Personally as a web developer I'm used to the idea that a URI identifies a resource and it has always made sense to me that a web app be identified by its manifest URL. If a resource is superceded by a new resource (as opposed to a new version of the old one) I would have thought the normal practice is just to redirect to it. As a user agent implementer I would far rather just fetch the manifest URL to check for updates than have to fetch a start URL, parse the HTML, look for the manifest link and then fetch the manifest. Especially if the start URL can change too.

@dmurph wrote:
> we only have people right now trying to create multiple PWAs in the same domain & struggling, or people updating PWAs & having new start_urls, which accidentally segments their userbase.

IIUC then using the manifest URL alone as an identifier rather than some combination of manifest URL, start URL, scope and content then the problem of accidentally segmenting users by changing the start_url would go away? Multiple PWAs per domain shouldn't be a problem either. Or am I missing something?

-- 
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-670479306