Re: [manifest] Handleing capabilities with Manifoldjs (#412)

(sorry, Jeff, for the huge delay ... I'm currently working on an internal project and have been neglecting my spec duties :()

On November 11, 2015 at 3:19:27 AM, Jeff Burtoft (notifications@github.com) wrote:
> I want to put something out there for feed back from this community. Manifoldjs is trying  
> to figure out how to manage it's capabilities. Specifically, we are allowing users to  
> add in cordova plugins to make those APIs available in the platforms that support. We  
> have two options, via the command line or via the manifest. The manifest would be prefixed  
> of course, much like our whitelist management is:
> ````
> "mjs_cordova": {
> "pluginMode": "server",
> "baseUrl": "/js/cordova",
> "match": ["http://shiftr.azurewebsites.net/profile", "http://shiftr.azurewebsites.net/users/*"]  
> }
> ````


I personally don't have an opinion about this. 

> We may collapse this with the current whitelist value, since we already manage scope  
> (and security for windows):
> ````
> "mjs_access_whitelist": [
> {
> "url": "https://bancocontoso.azurewebsites.net", "apiAccess":"all"
> }
> ]
> ````
> *Q1: Does anyone predict capabilities needs within the manifest directly that we can  
> align to?*


My prediction and hope (wish?) is that we won't ever require such a mechanism. I've argued why here:
https://marcosc.com/2014/12/why-manifests-and-permissions-dont-mix/

(tl;dr: we are working on the Permissions API which should afford developers with a more sophisticated way of doing permission requests within their applications. I worry that the above leads to "up-fron't" permissions requests, which Android has already switched away from, iOS has never embraced, and doesn't match how we do permissioning on the Web) 

> Next, we are considering enabling developers to be able to add js files to a page via the  
> manifest, that wouldn't be added to the page when it's not an app. This makes it easier  
> to add js that consumes app only APIs. It would look something like this:
> ````
> "mjs_custom_scripts": [
> {
> "source": "js/barcode-scanner.js"
> },
> {
> "source": "http://mydomain.com/js/photo-capture.js",
> "match": ["/pictures/*", "/user/profile"],
> "platform": ["android", "ios"]
> }
> ]
> ````
> *Q2: Is this opening Pandora's box? It's a big ask from developers, but I don't know if  
> it will lead to bad habits in the future.*

I'm personally not a fan of this for a few reasons: 

1. we have a fairly robust way of including scripts on the web, including the ability to include them dynamically. 
2. it adds more indirection: e.g., when should the script actually load? after other scripts, before, after the user installs, etc. 
3. Should the scripts be loaded in order, sync, or async? 
4. there would be limited recovery opportunity, as you could not access the events of the script loading machism (i.e., there is no script tag, so you lose all the value you get from it)  

I'm all for Manifoldjs to experiment with this, however. I think we can learn a lot from how developers would use something like this. For instance, we could in the future add a conditional `media` attribute to the script element to only load if the `display-mode: browser` matches one of the conditions in the spec. That would allow special scripts to be loaded as needed.

Hope that makes sense! 






---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/412#issuecomment-160492904