- From: Daniel Murphy <notifications@github.com>
- Date: Fri, 14 Aug 2020 13:00:42 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/674248967@github.com>
@benfrancis wrote > The reason that I ask is that the cost of fixing this (potentially hypothetical) problem by adding an additional identifier is that updates could become a lot more complex. It's much simpler to fetch a fixed manifest URL to look for updates than to have to figure out what document belongs to the app (bearing in mind start_url and scope can change), parse the manifest link relation from that document's HTML and then fetch the manifest The algorithm that we use is to basically visit any manifest links we see and then update if the identifier matches (for chrome desktop this is start_url). This code path used for install detection as well (and for setting theme color, etc, manifests are always supposed to be visited) , so it's not too much of added complexity for us to check all manifests we see because we do that anyways. Not sure what android does. @benfrancis wrote > I suggest the underlying problem here is just that the specification currently doesn't specify what the identifier of an app is or how apps are updated so developers are left to guess what user agents use to identify their app and each user agent may do something different. I think this is exactly right. Declaring the manifest_url to be the authoritative 'ID' would also work, as long as all user agents behave as such (i.e. we can get that into the spec). Would you be OK with the conclusion here to use 'manifest_url' as the unique identifier for a web 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-674248967
Received on Friday, 14 August 2020 20:00:57 UTC