On Friday, July 26, 2013 at 6:36 PM, Matt Basta wrote:
> The use case for a "supportsManifestVersion" API would be to allow > marketplaces to determine whether they should show an app to a particular > device. Imagine this scenario: > > Acme App is for sale and uses manifest version X > User's device implements up to manifest version X - 1 > > If a marketplace doesn't know and can't detect that the user can't physically > install the app (because their platform is too old or too new), then the user > could be sent through a payment flow (navigator.pay), purchase the app, and > then find out later that the app isn't able to be installed on their device. We would only really need this if we add things to the manifest that break backwards compatibility in an unrecoverable way (I don't think we have done this yet?). The consequence is that users might be unnecessarily locked out of content. For example, if a developer copy/pastes someone else's manifest and doesn't actually understand the implications of using manifest_version="2". Or, the developer decides to use some feature Z, but also makes the content available through graceful degradation (this makes using graceful degradation pointless - as by opting into version N you automatically shut-out - or at least annoy with a prompt - users). As the user's runtime can't predict the future (if it can support version x or not), it can unwittingly lock the user out of content - in a particularly discriminatory way. The fundamental flaw here is really with the business model that is guiding technical decisions (purchasing a unit - rather than paying to access a service). On the Web, there is no reason to not allow "try before you buy" to overcome the "but will it work?" problem. One way around this would be to have the freedom to keep adding members to version 1 of the manifest format (if those properties don't affect compatibility), but then have a "restricted" version. I'm again not in favor of this, as it's user hostile and doesn't scale well (e.g., as a user, I own multiple devices, each supporting different device capabilities, browsers, etc.). Also, as I have mentioned elsewhere, manifest metadata should remain orthogonal to device capabilities. > Having an API would allow the Marketplace to hide or blocks installs for the > app. Similar APIs exist for the <video> and <audio> elements to detect codec > support. The above API is an unfortunate byproduct of the Codec Wars™ - certainly not something to be emulated or that can be compared to, IMO. > Having such an API would be critical for forwards and backwards compatibility. > I think you might be correct but only for packaged apps - which sadly follow a traditional software development model (no "try-before-you-buy" support). However, a fundamental shift in thinking about what differentiates hosted apps from traditional [packaged] apps is needed here (i.e., Google's Play and Apple's iOS business models are incompatible with the decentralized/un-versioned nature of the Web). Thus, the proposed API should never be needed for hosted apps because it would be inexcusable to get into the "but will it work on my device?" situation. The role of the payment API in this context is to enable access to functionality/service/products (some examples are purchasing private repo access on GitHub, buying games on Steam, purchasing a physical good on Etsy, and so on). -- Marcos Caceres _______________________________________________ dev-webapps mailing list dev-webapps@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-webapps
