Mounir, this sounds reasonable to me. Google also had to version their manifest file to deal with changes they introduced in v2 but still wanted v1 manifests to work properly and retain their original syntax and semantics.
Cheers, -Travis ----- Original Message ----- From: "Mounir Lamouri" <[email protected]> To: "Marcos Caceres" <[email protected]> Cc: "Vivien Nicolas" <[email protected]>, "dev-webapps" <[email protected]>, "Matt Basta" <[email protected]>, "Jonas Sicking" <[email protected]>, "Tim Guan-tin Chien" <[email protected]> Sent: Tuesday, June 18, 2013 5:41:57 AM Subject: Re: Migrating to W3C format, was Re: Icon sizes and display densities On 17/06/13 19:49, Marcos Caceres wrote: > > > > On Monday, June 17, 2013 at 6:01 PM, Matt Basta wrote: > >> I don't think this is viable solution since it's not backwards compatible. >> Older devices won't be able to understand the manifest. > > So, we are probably going to keep hitting this problem going forward, as we > are not standardizing just Mozilla's manifest format (we are trying to learn > from all available formats to create a solution that is right for the Web). > Other W3C members have their own requirements, etc. and they've been quite > welcoming of Mozilla's manifest as initial input - but the reality is that > stuff is probably going to have to change in ways that may break > compatibility with our format. > > Question is, what's the best way to handle breaking changes? Jonas and I have been talking about this a couple of times. This is something that also applies to APIs. If we change an API to something drastically different we might want to be able to do that without breaking too many applications. A solution to do this would be to introduce a property in the manifest file like "manifest_version" or "api_version" or "platform_version" (whatever...). The manifest parsing would depend on the version number and the available APIs might too. Some manifest properties and APIs would only be available to newer versions and we could deprecate older versions and then even stop supporting them. The problem of that solution is that it sounds pretty specific to implementations trying to experiment things. We could definitively make this Mozilla only with something like "platform_version": "tef", "platform_version": "leo", ... Then, the W3C specification might or might not specify a system where there is such property (which would have different set of values). How does that sound? -- Mounir _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
