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 Tuesday, 11 September 2012 11:47:46 UTC