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

@philloooo wrote:
> I agree. The scope is a better choice if not considering change of expecations from one set of devs.

I also agree scope makes more sense conceptually than start URL. One other concern I have about scope though is that web apps may eventually need to support an [array of scope URLs](https://github.com/WICG/pwa-url-handler/issues/23#issuecomment-771718401), so it could end up being a compound key which is less neat.

> Oh thanks for pointing out, I just found out the announcement of them dropping the support recently. I will remove firefox desktop from the doc.

Firefox desktop has never supported installing web apps from a web app manifest. The recent decision to end the single site browser experiment doesn't change that, but it does remove one path to getting there.

> I think this is misrepresenting what I was saying in the doc.

Sorry if my summary came across as a little cynical, I'm just a bit frustrated with how this has played out over the years.

> I also tried to explain in detail that doing 301 redirect for use case of changing manifest_url either doesn't really support the use case, or ends up with unreliable behaviors for user agents.

I still think this could be workable. The worst case scenario is that users end up installing duplicate apps on the same device (if they don't remember they already installed it) or with different manifest URLs across different devices, which need de-duping as user agents follow redirects or synchronise with a server. I don't think it would be necessary for documents to always link to the original manifest URL, or for user agents to check all their manifests every time they encounter a new one.

Regarding the disadvantages you list for using processed manifest URL as a global ID...

>>  -    S2: installed apps on desktop, S3: Apps that are installed on both Android and desktop needs migration.

Why would Chrome for Android need migration if it already uses manifest URL?

>> -    Change of implicit expectations for desktop WebApp developers

Whatever solution is chosen, the behaviour of some user agents (including at least one of Chrome desktop and Chrome for Android) will need to change

>> -    S6: Apps that specify manifest as data URL will not be updatable

Agreed, but this already isn't possible on most user agents today (Chromium desktop being the exception). This seems like a reasonable tradeoff given it is inherent in the nature of data URLs. Developers can switch to an HTTP manifest URL if they want to start supporting updates, requiring a one-off re-installation.

>> -    PWA stores will recognize different versions of manifest URLs as different web apps.

Depending on how PWA stores collect manifests (developer submission/user submission vs. web crawling) they may temporarily end up with duplicate records which need merging the next time a listing is updated. I agree this is the biggest disadvantage (and impacts sync services too), but I am of the view that developers should be discouraged from versioning their manifest URLs (like 92% of existing web apps), which would help reduce the impact.

>> -    S4: Apps that need to update manifest URLs will need to keep supporting the previous manfiest_url, handle 301 to the latest manifest forever. The document will need to always use the original manifest_url. An extra roundtrip will always be needed for loading the app.

I agree with the first point (in theory), but disagree with the second two points. Documents should always be able to link to the latest manifest URL.

>> -    If the manifest_url is hosted under a CDN, they will need to stick to that CDN provider.

I don't agree, they can redirect to a new one.

>> -    Difficult to reconcile with S8: apps installed from A2HS, which does NOT require a manifest. ID creating here is weird, and instead would have to have custom upgrade handling for when a manifest is found on the page.

I think fake apps should be considered out of scope given they don't follow the specification anyway. Fake apps could use a generated chrome:// URL as a manifest URL. If a manifest is later found on the same page I would argue it is desirable for that to be treated as a separate application to a fake app.

> Most of the user agents you are listed are chromium based.

Yes, only Firefox, Kai OS and Safari are still using something other than Blink 🙁.

Do you think it's safe to assume that all Chromium-based user agents behave the same way as Chrome on desktop and on Android? (Genuine question as outside of the implementations I've worked on myself I don't know). Due to the interplay between the browser engine, browser chrome, underlying operating system and sometimes app store and sync service, evaluating support for the Web App Manifest specification is more complicated than for other web specifications which are implemented entirely inside a browser engine. Chromium-based user agents could have different browser chrome which implements add to home functionality differently, or use their own sync service or app store (Webian Shell for example is built on a desktop build of Chromium but uses manifest URL to identify web apps). Operating systems may also try to update apps independently of the browser they were installed from (I'm not sure whether this is currently the case).

> As I stated in the doc, safari doesn't support updating/looking up installed PWAs, so it doesn't add any use cases relevant to the unique ID problem.

I don't think it's fair to exclude Safari from the analysis on this basis, given the specification doesn't currently define how to update a manifest it can't be expected for user agents to already support this. As I understand it Safari on iOS does store metadata from web app manifests when adding web apps to the home screen, so what it uses as an identifier to store those data still seems relevant. It should be assumed that Safari on iOS may support updating web apps in the future, if and when that feature is defined in the specification.

As I understand it Firefox for Android doesn't currently support updating manifests either.

I've chatted with people who work on Firefox for Android and KaiOS and tried to encourage them to contribute to this discussion. From what I can tell, Firefox for Android currently uses start URL to identify web apps. The upcoming release of KaiOS uses manifest URL.

I think if you count the number of user agents (including all the Chromium based browsers on Android), there are probably more user agents which currently use manifest URL than start URL.

> I'd be interested to know any use cases that I am missing in this doc.

The remote installation and link relation use cases I mentioned above aren't explicitly called out as use cases or requirements, but they are mentioned within a couple of the possible solutions.

>> Out of scope
>>  - For a given id scheme, migrations between unique ids won’t be handled.
>>  - Migrating between origins.

FWIW if these weren't out of scope, it might be possible to handle both use cases with manifest URL as ID, using redirects.

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