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

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.   

In Widgets, we overcame this issue by allowing features to be declared as optional. However, some did try to do what you are proposing (e.g., WAC): they tried to disable Geolocation and only enable it through a feature… this became a huge issue for implementers (you can't disable it in an Android Webview, hence you can't implement these requirements using a Webview on Android or possibly on iOS).   

I would say this only be used for proprietary hooks, as is currently done with Chrome extensions (or with opera extension in the XML equivalent). Features have a role, but not for enabling/disabling bit of the Web Platform.  

--  
Marcos Caceres

Received on Friday, 25 May 2012 14:58:13 UTC