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

Hi, 
I also support having both DOM-event mechanisms for on-device senors and using web intents to bind to off-device sensors, I think there are valid scenarios where each solution is applicable and see no reason why the solutions cannot co-exist. 

Since external sensors can be reached through a lot of different ways (Bluetooth, local wlan, cloud, etc) and have quite varying capabilities and configurations I think a good idea to start with is to have a couple of initial scenarios to investigate.

Best regards
Niklas



-----Original Message-----
From: Nilsson, Claes1 [mailto:Claes1.Nilsson@sonymobile.com] 
Sent: den 11 september 2012 13:47
To: Rich Tibbett; DAP; public-web-intents@w3.org
Subject: RE: When should a Device API be exposed? Re: Atmospheric pressure sensosr API

Thanks Rich, this makes sense.

I have another opinion than Mozilla on Web Intents based APIs. To make do Web Intents useful and interoperable we need to specify APIs/protocols. We currently have Pick Contacts and Pick Media but I also would like to further explore how Web Intents can be used for use cases that require a longer lasting relation between the Client and Service, e.g. sensor related use cases. I'll try to allocate some time for this.

BR
  Claes

>-----Original Message-----
>From: Rich Tibbett [mailto:richt@opera.com]
>Sent: den 10 september 2012 18:10
>To: DAP
>Subject: 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 Thursday, 13 September 2012 13:45:01 UTC