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

@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

<br>

@dmurph wrote:
> 1. cross-origin migration is a non-goal here. But if we make the IDs unique (instead of semi-unique), then that might be easier? I'm not trying to tackle this problem right now, we dont' have requests for it, 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.

Ok, gotcha.

<br>

@dmurph wrote:
> > 1. I'm wondering about the migration strategy from the current world. If we say that an empty ID will default to the Manifest URL, then all current apps already have a default ID assigned. How do they migrate from this default ID to their new desired explicit ID without losing all their current users?
> 
> They would have to use their old manifest url as their ID, forever. Or whatever we have as default. I guess we could have some custom spec language here around "if you didn't have an ID and you set one, then that is the ID, as long as the manifest url matches"?, but that might be complicated. Open to thinking about that though.

Makes sense, thanks.

<br>

@dmurph wrote:
> > 1. It seems to me that there's almost zero benefit of an app specifying a relative ID. Possibly even a negative benefit, since some devs might think specifying an ID is protecting them and allowing them to move their Manifest URL, and they will end up accidentally breaking their app when the ID changes after a manifest move. What's the point of allowing a relative ID? Why not make absolute IDs mandatory?
> 
> Sure, I don't mind them being absolute / globally unique. It seems weird though as basically prepending the origin to the id would basically make it unique, so we could just do that for them, and say it only has to be unique for the origin. Question - how would the ID change after the manifest move? The ID must stay the same to move the manifest & not break people. Not sure why absolute is necessary here.

Sorry, I think I was responding specifically to this:

@mgiuca  wrote:
> I think the best way (i.e., most consistent with how other manifest keys like this work) to express this is that the ID is a URL that must be same-origin as scope*. This URL is resolved against the manifest URL, like every other URL in the spec. This URL is never requested, it's just used as an identifier.
>
> Making it a URL like this and requiring same origin gives it a natural uniqueness per origin.
>
> This means if your manifest is on a different origin to your start/scope, you must specify the ID as an absolute URL (same as all the other URLs). And it means if your id is path-relative, moving your manifest would change the ID, so you have to be careful to keep the ID stable when moving the manifest. We would recommend always specifying the ID as path-absolute (e.g., "/my-id").

Which I guess we haven't actually landed on.

<br>

@mgiuca  wrote:
> > Also, it seems potentially weird to have multiple manifests all be part of the same app.
> 
> Well. "Multiple manifests" is a bit hard to define (if a manifest changes its content or its URL, is that "multiple manifests"?). Essentially the entire point of this ID _is_ to formally identify when a manifest change represents a new app, versus a mutation of an existing app.
> 
> Using a different manifest URL _is_ the [currently recommended and only viable way](https://www.w3.org/TR/appmanifest/#internationalization) to provide localized manifest metadata. So we have to support that, unless we want to block on #676 (properly supporting localization). I think this works fine: you would make all of your different-locale manifests have the same ID, so they all represent the same app. Whichever manifest was served at install time determines what language you see. That way, if the user changes their language, and the start URL starts pointing at another language's manifest URL, the browser's updater will go "aha, I'll update to a new version of the manifest" as opposed to "that app is not installed". (This is _exactly_ the point of having an ID, so we can distinguish those cases.)
> 
> Going back to what @benfrancis said, the same answer applies:
> 
> > What happens if two web app manifests provide the same ID?
> 
> 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.

Right, this all seems reasonable. My main concern was developers accidentally (via copy/paste error, probably) specifying the same ID for multiple different apps, which would result in a pretty weird state. I'm probably overthinking this point, though, as it seems likely to be an infrequent case.

<br>

@benfrancis 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 read and comment on the other issue about that.)

I tend to agree with "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". But it's also true that if the manifest being served depends on the user's IP address, for example, then while travelling, they could end up getting install prompts for a different language of an app they already have installed, because the user agent has no way of knowing that these are just two different localizations of "the same app".

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