- From: Ben Francis <notifications@github.com>
- Date: Mon, 06 Apr 2020 15:01:44 +0000 (UTC)
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/609848869@github.com>
> We'd have to come up with our own scheme, like "webapp://example.com/user-specified-id". This is basically what we did with Firefox OS, where we created URLs like **webapp://1dd47458-abac-4637-b7e6-12c6e0ef9846**. With [hindsight](https://medium.com/@bfrancis/the-story-of-firefox-os-cb5bf796e8fb) I think creating a protocol scheme and namespace separate from the web was the biggest single technical mistake we made on the project, because over time it allowed applications to evolve into something which was missing many of the key benefits of the web, especially linkability. This is one of the [key principles](https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/) of "Progressive Web Apps". > *By the way, I'm avoiding use of the term "URI" simply because the URL Standard says that the term "URI" is deprecated in favour of "URL". I personally think it's useful having a distinction, but I fought this years ago, and gave up. Yeah I was just using the terms to distinguish between a URI which _identifies_ and app and a URL which can be resolved to _locate_ its metadata, but what I'm advocating for is a manifest URL which serves both functions. My understanding of the proposed use cases for an ID in this thread are: 1. Uniquely identify a web app in a directory or app store 2. Uniquely identify a web app when the metadata in its manifest is updated 3. Sync installed web apps across devices, even if the server serves slightly different manifest metadata to different user agents With the additional requirements: 1. An ID which is guaranteed to be unique within its origin 2. Ideally have backwards compatibility with user agents which have used manifest URL as an ID in the past 6. Allow developers to change the URL of a web app manifest when needed and migrate to that new URL 7. Enable caching a manifest and invalidating the cache of a manifest Using the manifest URL to identify the app seems to me to fulfill all of these requirements. It can be used as a globally unique identifier (which is therefore also unique within its origin), can identify an app even when the contents of the manifest is updated or differs between user agents, allows cache control using cache headers and can be migrated to a new URL if necessary using HTTP redirects. It also has the benefit that it doesn't require inventing a new URL scheme for a new non-web namespace for installed web applications and doesn't require an algorithm to derive the identity of an app from multiple inputs. And finally, it has the benefit of providing a potential simple update mechanism which the manifest specification still doesn't have a solution for. -- 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-609848869
Received on Monday, 6 April 2020 15:01:59 UTC