On Monday, June 24, 2013 at 7:48 PM, Jonas Sicking wrote:
>
> My thinking was to use some sort of versioned manifest for now, as long as we
> only use it in prefixed mozApps.install.
>
>
> Once we switch to an unprefixed function, we also need to use a standardized
> manifest and forever maintain compatibility with that manifest format.
Ok, here is a shot at this to get the ball rolling… Below is a quick straw
person Mounir and I put together over IRC.
In order to limit potential issues with breaking changes in the FxOS manifest
going forward, as well as to provide us with a way to add new (non-backwards
compatible) features through the FxOS manifest format, it was proposed that a
versioning scheme be introduced. It is assumed that the user agent will
continue to support legacy content indefinitely (that is, all V1 content going
forward).
# The `manifest_version` member
The `manifest_version` member denotes the manifest version used by the
application. It's type is expected to be a non-negative integer greater than 0.
Notes on the type: ECMAScript's ToNumber() algorithm is used to perform the
conversion from JSON, hence the following are all valid and equivelent: "2", "
2 ", 2, [2].
## example of usage
{
...
"manifest_version": 2
...
}
##Authoring guidance and validation
Unless version specific members are included in the manifest, it is optional
for a developer to include the `manifest_version` member. When the member is
missing, the user agent assumes the value to be 1. However, if version specific
members are included in the manifest, and the `manifest_version` is missing or
in error, then members that rely on `manifest_version` to have some effect will
be ignored by the user agent.
A manifest validator must validate that `manifest_version` contains a
non-negative integer greater than 0.
Note: Future versions of FxOS may require the `manifest_version` member to be
present in a manifest, and to be set to at least the number 2 (e.g., if some
future member becomes required for security reasons). However, legacy content
should continue to work and offending members may end up being ignored by the
user agent.
## Steps to determine the version number
The following steps take a JSON-parsed manifest as an argument. The steps
always return a non-negative integer greater than 0.
1. If the manifest does not have its own property "manifest_version", return 1
and terminate this algorithm.
2. Let potential-version be the result of running ECMASscript's
ToNumber(manifest_version).
3. If potential-version is a NaN or a number less than 1, warn the developer
that the version is invalid. Return 1 and terminate this algorithm.
4. Return potential-version.
## Outstanding issues
If version is greater than the highest version number supported by the user
agent, should the user agent treat the manifest as the highest manifest version
it supports? Or reject the manifest outright as invalid?
If a manifest version number is invalid (i.e., NaN, <= 0 ), is the manifest
invalid?
--
Marcos Caceres
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
