On 23/05/13 16:36, Matt Basta wrote: >> How do you know that an update is incompatible? > > The marketplace currently generates a feature profile, which the marketplace > API can understand and decide whether the app is compatible with the device. > The platform/OS have no knowledge of this, and just poll whatever URL is > thrown at them for updates. In this case, the mini manifest URL is the > Marketplace API, which could decide whether to serve an update or not.
Doesn't the manifest contain the list of required feature? Can't that be used by the runtime to ignore some applications? > Could this go in the manifest? Sure, but then the client needs to know about > every single feature that we sniff for, even ones that Firefox > OS/Android/Desktop don't support. I'm not sure I understand what you meant here. Do you have examples? > Also, warning a user that an app update isn't compatible is a little cruel: > they can't get the update regardless, so why taunt them about it? "Your phone > doesn't support the new version of the app. Too bad!" There's no action > there. The user can't choose to do anything differently in many cases. This is a UX issue but as a user I would like to know that I do no longer get updates because my OS/device is getting too old. A user my trying to push the developer of an app to get the latest version working on its device or even change device or switch to an alternative application. >> Hosted application have identifier based on their manifest URL so the >> runtime can take care of that. > > If the runtime is polling the Marketplace, that's a bad thing and works > against the idea of federated marketplaces, and is partly why hosted app > blocklisting doesn't exist today. Hosted app manifests don't live on > Marketplace servers, and not all apps may have been installed from the > Firefox Marketplace. I do not think the marketplaces should be put in the centre of the system because you can install hosted applications from anywhere so you can't make the marketplaces owning the blacklist of applications. As I said, having Mozilla taking care of blacklist for its runtime is probably the best solution so if a user is using another marketplace than the one from Mozilla, that user would be as safe as anyone else. This is a mechanism we use for websites and extensions. >> Can't the runtime be clever and if there is an HTTP REDIRECT when trying to >> update a manifest? > > Consider the case of Bit.ly a few years ago when there was that big scare > that Libya was going to retract all of the LY TLDs. If an app owner suddenly > lost control over their domain for legal reasons or otherwise, their app is > permanently broken on all users' devices, and potentially could be hijacked > by a third party in the future. Isn't that a problem you have on the Web in general? If someone takes over your domain, you are screwed. If I host a popular web page or web service that attracts a lot of users and suddenly, I do no longer own the domain, all my users will be in danger because they trusted me but not the new owners. Given that hosted web applications are no more than web applications with a manifest to make their integration in the runtime better, trying to solve this problem does not seem to be in scope. -- Mounir _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
