Explicit requirements/capabilities section

[jfey]

What about an explicit section for app requirements/capabilities to make sure, that the app will be loaded/run only if capability matching gives it a go. Like:

"capabilities": [{
    "camera":  [{
      "minCam": 1,
      "maxCam": 5,
      "minFps": 25,
      "type": "video/mp4"
     }],
    "mic":  [{
      "optional": "false",
      "type": "audio/wav"
     }],
    "interfaces":  [{
      "WebRTC": "true",
      "SignalR": "true"
     }]
  }]

This could be very useful for PWA, service discovery and more embedded use cases etc.

Juergen

[reillyeon]

Can you elaborate on the use cases? I'm concerned that this shifts the burden of showing the user a good message about why an application is not compatible with their device from the application to the browser and the browser is likely in a worse position to do that properly.

[marcoscaceres]

Yeah, we definitely don't want to add anything like this. On the web, we require developers to ask users for permissions at time of use.

Closing as duplicate of #319

Please see also:
https://marcosc.com/2014/12/why-manifests-and-permissions-dont-mix/

[jfey]

Hello again,

The proposal was not about permissions etc - it was about capabilities and the matching/filter process. It would help to get the right app onto a device. The permission game is a different beast and works when the app is loaded and running. Agreed.

Capability matching would help any discovery stage for complex/intelligent web components or app. I know - this kind of stuff is currently more oriented towards vertical/embedded solutions but it could also be of importance for mobile apps or TV sets. After browser based apps did loose against QT and other UI solutions big time in the past (i know this first hand) now time has come to come back to the browser based UI/UX approach. We are talking millions of devices - from kitchen appliances to smart home systems to ebikes to cars to infrastructure.

Not all components of a solution may be known right at initial compile time - but there is still some need to discover newly available components and to add those during runtime in a dynamically fashion.

Maybe i was not clear enough about the scope/impact/direction of the proposal.

[marcoscaceres]

The scope is clear... sorry for conflating this with permissions. However, the principle stands: we definitely don't want to add this kind of thing to the web, as web technologies try to be device/capability independent (as much as possible). For instance, say with fps... that's not possible to determine, because it's variable and could be based on a number of factors (e.g., low battery could slow down the gpu or cpu, as happens on Macs). Same with say, "mic"... a user could unplug or plug in a new one at any point, and so on...

[jfey]

Marco,

At least i gave it a try ... :-)
I completely understand your position.

Do you know of discussions/groups inside of W3C, which are covering these kind of (my) issues/topics?

[marcoscaceres]

@jfey, best place to discuss is https://discourse.wicg.io . Happy for you to expand on your ideas there and maybe we can find some kind of compromise or new thing to add.