> We would only really need this if we add things to the manifest that break > backwards compatibility in an unrecoverable way
Not the case. This feature is needed in order to prevent older devices from accessing content that they can't run. The app ecosystem can't rely on developers being good samaritans and always providing backward compatibility for every feature forever. > (I don't think we have done this yet?). We're presently dealing with the fallout from the addition of the `origin` field (albeit a packaged app-only field). It's not inconceivable that this will happen again. > 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. Yes, but we live in a world with payments and apps that cost money. If a user pays for an app that requires a specific feature that's not supported on older platforms, the user is going to be really upset that they spent good money on an app that won't run. It should be preferred that users can't install an app spuriously rather than being able to pay money for it and then being unable to use it. The implementation that the Firefox Marketplace uses doesn't disallow the install, we simply warn the user up and down that the app probably won't work if we think that it's incompatible with their device, and we also don't list it in search results with the default settings. Imagine if you bought a car, but only after you'd signed the loan contracts you found out that it had the steering wheel on the opposite side that you're used to. The car doesn't function the way you'd like it to, and now you're stuck with it. That's a really crappy experience, and I'd rather have a nag screen than users clamoring for refunds or sending chargebacks. > manifest metadata should remain orthogonal to device capabilities. It's presently the case, and it seems (based on the drafts of the manifest spec) that the manifest contains fields that affect the functionality and behavior of the app. In fact, most of the fields in the Mozilla manifest docs affect the behavior of the app and aren't "metadata" at all. > 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. Even now, this is false. Hosted apps can still require payment, and any hosted app can check that a proper receipt exists. There is nothing that requires a hosted app to support a "try-before-you-buy" or "freemium" model and it's unlikely that this will ever change, at least for the Firefox Marketplace. ----- Original Message ----- From: "Marcos Caceres" <[email protected]> To: "Matt Basta" <[email protected]> Cc: "Mounir Lamouri" <[email protected]>, "Vishwanathan Krishnamoorthy" <[email protected]>, "dev-webapps" <[email protected]>, "Vivien Nicolas" <[email protected]>, "Tim Guan-tin Chien" <[email protected]>, "Jonas Sicking" <[email protected]> Sent: Monday, July 29, 2013 10:43:38 AM Subject: Re: Versioning system for manifest, Re: Migrating to W3C format, was Re: Icon sizes and display densities 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 [email protected] https://lists.mozilla.org/listinfo/dev-webapps
