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

Nilsson, Claes1 wrote:
> So Rich, are you proposing two sets of sensor APIs?

I'm proposing one set of sensor APIs (on the DOM) and there is another 
abstract pipe over which you can send whatever you want (Web Intents) 
which may, coincidentally, contain barometer data.

I'm suggesting that either approach is not mutually exclusive to the other.

>
> 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.

One is a direct API interface with a specific, well-defined purpose that 
is provided directly to web pages in every browser under the sun. The 
other is an interface to a 3rd-party application that may or may not be 
available on the host device, that may or may not provide local 
barometer data and may or may not provide that information in the same 
format as all other Web Intent based barometer implementations.

It's true that given a pipe you can send any information you want over 
it. You could extend the Web Intents argument to any DOM-based API you 
like, existing or new. That doesn't mean we can't define something that 
does one thing and one thing well and, in doing so, has the least moving 
parts possible i.e. a DOM API.

- Rich

>> Josh Soref wrote:
>>> This entire approach is also why I'd much rather we do these APIs as
>>> Intents.
>>> 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.

 > Rich Tibbett wrote:
>>
>> 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.

Received on Monday, 10 September 2012 16:10:07 UTC