On Monday, July 29, 2013 at 7:13 PM, Matt Basta wrote:
> > 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.
An API is not in the position to make this determination. It's just a way to
side step a halting problem with unintended side-effects: you can't know if you
can run the code until you try to run it.
> The app ecosystem can't rely on developers being good samaritans and always
> providing backward compatibility for every feature forever.
I think this is where we fundamentally disagree - this is a core tenant of the
Web and Web applications. I put this burden on browsers in that I believe that
browsers have an obligation to continue to support legacy content so long as a
% of that content is on the Web. Developers should be expected to have their
applications degrade gracefully - HTML is designed around this principle and
these sort of APIs threaten to break this core principle of the Web.
> > (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.
Adding origin is not a breaking change, AFAIK? It just means an app gains a
stable human readable origin rather than a UUID.
> > 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.
But they are still going to be pissed off if they purchase something on device
A, but it doesn't get installed on device B - specially when they got sold on
something being a Website that should work on both devices by its very nature.
> 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.
Feature detection is only the tip of the iceberg of things that could prevent a
user being able to use an application (e.g., an app expects a real keyboard or
touch screen to be present, there is no network connection, some service the
app depends on goes down, a regression in the OS slips through and causes the
app to stop working, not enough memory on the device, etc.). The fundamental
problem is still that they are getting potentially blocked from doing something
in the first place with a technology that was architectured to not get into
this situation (i.e., that degrades gracefully).
> 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.
Sure, but this is a problem because it gives developers an escape hatch to not
degrade their apps gracefully.
> 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.
This is a bad example, because cars are the quintessential "try before you buy"
- I don't know anyone who has bought a car without test driving it first. That
aside…
> 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.
Now imagine, you buy the car, but it's able to adapt to its environment: you
are out on the road, and the road suddenly turns to sand - the car
automatically turns into a 4x4… you drive into water, it suddenly turns itself
into a boat. You try to drive it through a wall, but it doesn't - so you tell
the manufacturer you want to be able to drive it through a wall and a few
minutes later, the manufacturer adds support for that. It's 15 years later, and
you can still jump into it and it behaves the same way it always did. Sure,
everyone around you is now driving flying cars that are able to go into space -
but you don't care because your car still works as well as it did after it got
its last service.
That's the beautiful thing about Web Apps - they are built to be adaptive - and
that's the beautiful thing about Web browsers - they don't lock people out of
their computers/phones/cars every 2 years like iOS, Android, and other
proprietary platforms do. Websites I made when I was a kid still work exactly
the same today as they did back then. Look - a page made in 1993 (and it
works!): http://info.cern.ch/hypertext/WWW/TheProject.html
> > 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.
Sure. By device capabilities I mean enabling things like APIs (e.g., the need
to declare geolocation in the manifest - which is redundant given that
geolocation already prompts on use, and that location services could be
controlled per application).
> > 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.
Sure. But do any? Does anyone buy these things. I don't think we sell any apps
at all ATM, do we?
> 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.
>
Take a look at the apps in the marketplace - the only category that resembles
is games. The others all seem to follow the freemium model.
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
