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: Nilsson, Claes1 <Claes1.Nilsson@sonymobile.com>
Date: Mon, 10 Sep 2012 16:51:11 +0200
To: Rich Tibbett <richt@opera.com>, DAP <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D79276F85@seldmbx03.corpusers.net>
So Rich, are you proposing two sets of sensor APIs?

1. The current DAP sensor APIs that work for specific sensors built into the user's current device.

2. Web Intents based sensor APIs to support discovery, selection and access to sensors hosted "anywhere".

Do we want to provide this duplication? The reason for going for a Web Intents based solution is that the need for Web Applications to use data from external sensors will likely increase. 

Best regards
  Claes 

>-----Original Message-----
>From: Rich Tibbett [mailto:richt@opera.com]
>Sent: den 7 september 2012 18:47
>To: DAP
>Subject: Re: When should a Device API be exposed? Re: Atmospheric
>pressure sensosr API
>
>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 Monday, 10 September 2012 14:51:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 14:51:51 GMT