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

@glennhartmann wrote:
> I'm pretty late to the party, but I have a few thoughts.
> 
> 1. Overall, iiuc, the main motivation for having an explicit ID instead of using Manifest URL is to allow the Manifest URL to change (including for versioning). It's been mentioned that the migration path for the app to find a new Manifest URL will be to load the Start URL and find the Manifest URL from the <link> tag.
>    So my question is, what if a developer changes both URLs? For example, if they migrate their whole app to a new domain or new subdirectory? Haven't we effectively just changed the problem to "yes, we can now move the Manifest URL, but _only_ if it's guaranteed that the original Start URL remains up-to-date and accessible forever"?
>    And to emphasize, this means the **original** Start URL. It's possible that existing apps that have already changed their Start URLs still have straggler users who haven't updated to the new Start URL yet. If they now move their manifest, will the straggler users be able to find the new manifest?


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.

> 2. Speaking of moving an app to a new domain, is that handled by this proposal? There's a lot of talk of unique-per-origin IDs. Does that mean moving to a new origin still qualifies as "making a whole new separate app"?


2) 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.

> 3. 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.

> 4. 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.

> 
> @dmurph wrote:
> 
> > I see the following issues with using manifest url:
> > 
> > 1. This locks developers into a CDN / the manifest url host. I can see a world where someone scraping manifests would see a ton of duplicate webapps here because they find links to lots of different manifest urls for the same app (versioned, or on different CDNs). There would all be separate apps
> > 2. This prevents versioning of the manifest in the name
> > 3. This makes it difficult to serve different manifests based on client hints like language, etc.
> 
> Could you elaborate on (3)? Do you mean that it would be better to have a set of manifests, one per language, for example, and they would all have the same ID (making them all parts of the same app), and then the start_url page would dynamically choose which to point to in the <link> tag based on client hints? Is that much more difficult than serving dynamic manifest contents from the same URL based on client hints?
> 
> Also, it seems potentially weird to have multiple manifests all be part of the same app. While there are legitimate use-cases (like translation), it opens up a potentially very confusing situation where completely different things will all be considered the "same" app (they could customize anything in the manifest - start url, name, color schemes, even scope, and we'd still consider it "the same app"). Yes, technically this is already possible by hosting a dynamic manifest, but this makes it a more explicitly "allowed" strategy, and one that could even be done accidentally.


Regarding my 3) - I think you're right, and I don't like that use case anymore. I'm a bigger fan of making the manifest multi-lingual, I think there are proposals here. I don't there there should be multiple manifests, just one per 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-670200889