- From: Ben Francis <notifications@github.com>
- Date: Fri, 03 Apr 2020 04:56:35 -0700
- To: w3c/manifest <manifest@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/manifest/issues/586/608392878@github.com>
@mgiuca wrote: > whatever the answer is, it should be specified and consistent across browsers. I agree. See also: https://github.com/w3c/manifest/issues/446 and https://github.com/w3c/manifest/issues/384. The "[Updating the manifest](https://www.w3.org/TR/appmanifest/#updating)" section of the specification has been empty since 2016 when the same-origin constraint was dropped for manifest URLs and default scope was defined as "unbounded" (later changed) which made things more complicated. Whatever solution is eventually specified for updates will obviously be influenced by what is used as the unique identifier for an app. Having a relatively stable manifest URI that can be fetched periodically seems like the obvious solution to me. When apps can have overlapping navigation scopes and start URLs can change, *something* needs to be stable. Migrating manifest URIs via redirects could work for occasional changes to app structure, but as you suggest it could get unwieldy if the developer tries to change the manifest URL every time the manifest's content is updated for caching purposes. In practice it might be simpler for a developer to just treat a significantly restructured version of the app as a new app, and use other strategies for caching/versioning. -- 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-608392878
Received on Friday, 3 April 2020 11:56:49 UTC