On Tuesday, 18 June 2013 at 13:41, Mounir Lamouri wrote:
> 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? I think it sounds ok for the Moz side (as we can control how long we support a format version for, etc.) - but adding a manifest versioning scheme for the Web platform (W3C-side) won't fly because it would be difficult to maintain across user agents. Also, feeding a Mozilla manifest to a W3C conforming implementation will also result in no icons (unless we change the name of the property on the W3C side as Matt suggested, but I doubt people will support that to accommodate legacy content from a single store - 'icons' is just too perfect a name to be owned by Mozilla). Another option to consider is the contract that is made between the app developer and the "navigator.mozApps.install" API. This API basically says "install a Mozilla-App" and not "install a W3C conforming app". To cut a long story short: there is no way to install a Moz app on a W3C conforming runtime. The W3C hosted app does not currently use any kind of install API (unlike FxOS, it relies on the <link> element to advertise it's "install-ability"). In practice, this would mean developers would have to keep two versions of their manifests: one for FxOS and another for W3C compatible UAs. I think that is ok as a transitional strategy. If the manifest is served using PHP, then it would basically just mean having some conditional code like: //request URL for w3c manifest example.com/manifest //request URL for mozilla example.com/manifest?type=mozilla If type = mozilla, then the developer can just conditionally filter out the mozilla stuff. Or you just have two files. For packaged apps, we can use a different file name on the W3C side to bypass this problem (config.json) or something. _______________________________________________ dev-webapps mailing list dev-webapps@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-webapps
