- From: Rich Tibbett <richt@opera.com>
- Date: Fri, 07 Sep 2012 18:46:41 +0200
- To: DAP <public-device-apis@w3.org>
Josh Soref wrote: > Marcos wrote: >> Sorry.. dumb question, but I can't ever remember the answer: if a hardware (or >> similar) capability is not available on the host device, should the API be exposed >> by the UA? I thought I had read somewhere (HTML spec? WebIDL?) that the UA >> should not expose the API when the capability is not available. >> >> I'm asking because I saw the following in the Atmospheric API proposal: "Not all >> devices contain a barometer, and when there is no barometer, this API is still >> exposed to the scripting environment but it does nothing". > > Yeah, that runs counter to the behavior we generally accept. > > This entire approach is also why I'd much rather we do these APIs as Intents. I don't quite follow that A -> B link in this context. There is a clear pattern for DOM API feature detection. We're just asking to implement that. We really shouldn't need to throw the baby out with the bath water here :) > > Doing it as an Intent allows the host to provide a host-OS/Device based Intent provider if it's available, but allows the user to connect a web service or Bluetooth device or whatever if they want to interact with the application but their hardware/OS doesn't have the necessary support. There are a few scenarios for this: 1. The browser implements the low-level Barometer interface and then provides the mapping from barometer data to a web intents barometer format. 2. A 3rd party yet-to-be-defined application exposes all Device APIs as Web Intents. These web intents are automagically registered and available in each user's web browser before they attempt to use any Device API based Web Intents. In the first case, if the browser is implementing the logic to make a Barometer 'speak' Web Intents then it makes little sense why we'd add that extra level instead of exposing it directly as a feature-detectable DOM API. In the second case, it seems like a move back to a web of plug-ins. Each device is expected to have this Web Intent-erizer app or the Device APIs don't work - even if the current device does have a Barometer. I'm not saying there aren't good cases when Intents make sense (e.g. a Contacts app with Picker UI) but why not just build the logic to handle Device APIs in to browsers if they're expected to talk to the low-level Device APIs anyway? That's much easier (no Web Intents layer) and much more reliable. If it's supported by the device it's supported by the browser implicitly. There is nothing stopping a 3rd party app providing these APIs over Intents if that's what they really want to do though. That really shouldn't be the only way though. - Rich
Received on Friday, 7 September 2012 16:47:12 UTC