Re: [manifest] features Re: Review of Web Application Manifest Format and Management APIs

On 05/25/2012 07:54 AM, Marcos Caceres wrote:
>
>
> On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote:
>
>>> Interested to see what could be listed here… this is the area of greatest interop concern, IMO (hopefully it won't be needed at all, as it's only really useful on extension/proprietary platforms).
>>
>>
>>
>> Examples include "touch", "webgl", "indexeddb". You're right that it's
>> possible to use this for proprietary extensions; but there are use cases
>> for standard web features. The idea is to let the store and runtime have
>> some control over not allowing the user to purchase/install/launch an
>> app that is known not to work on their current device.
>>
>> For instance, if I am browsing for apps on my phone that doesn't support
>> WebGL, the Mozilla App Marketplace won't let me install any apps that
>> have that feature listed in required_features. Likewise, the runtime may
>> prevent launching apps that are known to be incompatible with the
>> current UA, quire similar to screen_size.
>
> I think this will quickly become unmanageable. It means you need to take the current web as it is today, freeze it, and then start hiding all future functionality that can only be enabled through this list (and the list of things you need to enable grows forever or you end up having to enable unexpected things, which then may cause security issues that the developer was not expecting). Hence, features like this should only be used for things that are sure not to be part of the Web Platform.
>
> This also goes against the trend of responsive design: it means that I can't make an app that both uses WebGL and falls back to legacy tech because the store will refuse to install it on my non-webGL-phone. So as a developer, I would need to release two versions of the same app.

That is not the intent of the field. The "required" prefix indicates 
that these are *mandatory* features without which the application will 
not function at all. A camera app is no good without camera access, 
responsive design does not help.

In your example, if an app is able to fall back to legacy tech, then the 
developer is expected /not/ to list WebGL in this field, since it is not 
mandatory.

-Anant

Received on Saturday, 26 May 2012 17:36:14 UTC