On Tuesday, May 28, 2013 8:59:09 AM UTC-7, Matt Basta wrote: > > 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
"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." Matt is correct, you can't polyfill a feature that fundamentally does not exist given a missing hardware requirement it relies upon. Secondly, this form of feature detection and profile comparison is flexible enough that other marketplaces and apps can generate their own profile signatures that are tailored to their needs. For instance: If Nvidia wanted to create a Tegra Zone app that mitigated the installation of games intended for various levels of hardware and performance support, they could detect a profile, of their definition, on the user's device and show games that they know will run well on a device with those perf characteristics. I have reviewed the solution Matt presents, and it makes the most sense of anything I have seen or thought of to solve this problem. Paired with this feature - https://bugzilla.mozilla.org/show_bug.cgi?id=873599 - we can make it even easier to generate a base profile. This discussion is moving toward the region of "we should discuss this impasse face to face". Let's get back to addressing a bulleted list of outstanding concerns instead of circular, scatter shot mix of new and previously answered questions. TO DO: - Each of the skeptics should formulate single, deduped, bulleted list of their outstanding concerns here: https://etherpad.mozilla.org/app-profile-answers - Matt will provide answers for each - Ask follow-ups inline if need be Let's be in the business of solutions folks. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
