> Why was that abandoned? The first it was ever mentioned was 2012 and it's not supported by any of the devices that we're shipping. It's effectively a non-feature and won't be useful since it's not backwards compatible. Whether or not it becomes a standard is moot because it won't apply to the launch devices and that's what matters.
> I'm not sure of what "spec" you are speaking about. http://www.w3.org/2012/sysapps/manifest/#required_features-member Tracing the origin of the "required_features" field back, it first appears in 2012. > I believe the marketplace is reinventing the wheel here. That kind of > problems have already been solved in the web and things like input types > are being polyfiled. False. If an app needs to use getUserMedia to take pictures, that's supported on Firefox for Desktop but not FXOS. WebActivities are only available on FXOS (maybe Android?). If an app doesn't target desktop, it has to choose WebActivities. Any app that only implements one and not the other is physically broken on one of the two platforms. They could implement both, but then they can't sell their app since navigator.mozPay doesn't exist for desktop (or Android) yet. There are plenty of features that an app could require that are "proprietary" Mozilla APIs that simply don't let apps fit into the web as we know it. All of the WebAPIs, WebActivities, codec support (!), and the flavors of WebRTC are just a few which make this issue something which simply can't be addressed by conventional means. The Marketplace's feature profile addresses this issue fully and completely. Telling developers to use polyfills isn't sufficient because the apps already exist and the developers won't do it. We can't sell apps to people if their devices won't run the apps. Simple as that. If you pay for a music app, it damn well better play music or the user is going to be pissed. If the music app uses an API that's not supported on the platform they're using, it's our (i.e.: the Marketplace's) responsibility to not show them that app. By the time the user's device gets the manifest, it's too late to check whether their device supports the app because the user has already paid for it. > Why wouldn't carrier or third parties being able to plug their own > blacklist server in the device? We shouldn't make it the responsibility of the carrier to know when the Firefox Marketplace blacklists an app. That would be like saying that you can run Norton Antivirus on your PC, but the definitions come from Intel. ----- Original Message ----- From: "Mounir Lamouri" <[email protected]> To: [email protected] Sent: Tuesday, May 28, 2013 6:11:00 AM Subject: Re: API for editing existing app installations On 24/05/13 16:34, Matt Basta wrote: >> Doesn't the manifest contain the list of required feature? > > A very old version of the spec contains a "requiredFeatures" field, but it > was never fully defined and isn't supported, and no values for the field were > specified. Why was that abandoned? Also, it is being worked on in the specification so I'm not sure of what "spec" you are speaking about. >> I'm not sure I understand what you meant here. Do you have examples? > > If there's a new feature we want to add compatibility testing for that some > devices might already have, we can't rely on the devices to implicitly know > that they support the feature. If we decide, for instance, that we want to > detect support for <input type="color">, the user agent would need to be able > to say, "Oh, I know what <input type="color"> is and I do[n't] support it.". > > We already have this functionality in our feature profiles, so no sense in > reinventing the wheel. I believe the marketplace is reinventing the wheel here. That kind of problems have already been solved in the web and things like input types are being polyfiled. Granted some websites are locking out some users that don't have a particular set of features but <input type=foo> wasn't a good example and I believe that for those high level features that can't be polyfilled, we could use required_features in the manifest. >> 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. > > Right, and as I mentioned in my original email, a marketplace could only use > this API for manifests *which it installed itself*. Relying on Mozilla to > blacklist apps which were distributed by a third party who could otherwise do > the blacklisting themselves seems very bad. If carriers start distributing > their own branded marketplaces, making them go through us to flag and remove > malware seems like a dangerous and slow process. Why wouldn't carrier or third parties being able to plug their own blacklist server in the device? > Of course, but we're in a different boat than the web at large. I strongly disagree. -- Mounir _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
