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

@glennhartmann wrote:
> @dmurph wrote:
> 
> > I think the desire is to allow developers to change the start url & the manifest url. They would have to deal with the case that an old start url is still registered for various users forever, so they would have to handle that somehow. I'm not sure what the best route would be here - I'm guessing they have to somehow serve the new manifest on the old start url, OR they can redirect & serve the new manifest on the new start_url, and since the IDs will match up, then it can update.
> 
> Right, I guess mainly what I'm wondering is whether this is that much of an improvement over using Manifest URL. If we say that manifest url is the ID, then start url is already trivially updatable, like any other manifest attribute. Moving the manifest is also doable via HTTP 301 redirect. The main drawback afaict is that it requires an explicit action by the developer, and continued control or maintenance over the original manifest url.
> 
> It seems to me that the new proposal (unless we come up with a better migration process) has similar explicit action and maintenance required. We're just changing the problem for developers from "we need to redirect the old manifest URL" to "we need to make sure all previous start URLs continue serving content and point to the current manifest URL". Either way moving the start URL and manifest is doable, but requires explicit thought and work to get it right.
> 
> To be clear, I'm not against the idea of an explicit ID, I just want to make sure it's buying us as much of a benefit as we think it is, and enough to justify the cost of implementation.
> 
> There are a few benefits I can think of, but I'm not sure how big they are:
> 
> 1. changing static-hosted contents may be easier than issuing an HTTP 301 redirect in some cases
> 2. getting the migration wrong with an explicit ID is possibly more fixable than getting it wrong with a manifest URL
> 
> 

I guess, in the case where a website accidentally assumes they can just reference a different manifest link for an update, and that doesn't obviously break anything at first, is still an issue. We have already had partners make this mistake with start_url on desktop and they can't fix it.

Maybe we position the `id` as a way to fix this type of situation. `original_manifest_url`, or `manifest_url_override`, or maybe just `id` is fine. But it's basically a way for a website to fix this situation if it happens, instead of encouraging all people to use an `id`? Then your 'copy-paste' mistake case won't be as much of an issue?

My preference would be to:
* Add an `id` field that uniquely identifies the web app in the origin
* default this value to the relative manifest url (edge case here of the manifest being served in a different location than the start url, Matt has a scoping issue about this somewhere that probably solves it),
* encourage webapp authors to set it, and clarify that this uniquely identifies the webapp as a single webapp, and any manifest in that origin that has that id will be considered for the same webapp

BUT I'm also fine with framing it as a "fixing" field, and not encouraging developers to use it unless they have broken their population by moving their manifest hosting location.

WDTY?

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