W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2012

Re: When should a Device API be exposed? Re: Atmospheric pressure sensosr API

From: Rich Tibbett <richt@opera.com>
Date: Fri, 07 Sep 2012 18:46:41 +0200
Message-ID: <504A24F1.6060205@opera.com>
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 

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:55 UTC