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: Tue, 11 Sep 2012 13:47:17 +0200
To: Rich Tibbett <richt@opera.com>, DAP <public-device-apis@w3.org>, "public-web-intents@w3.org" <public-web-intents@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA35D792770A2@seldmbx03.corpusers.net>
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.


>-----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
>> 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
>>>> a web service or Bluetooth device or whatever if they want to
>>>> with the application but their hardware/OS doesn't have the
>>>> 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
>>> 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-
>>> DOM API.
>>> In the second case, it seems like a move back to a web of plug-ins.
>>> device is expected to have this Web Intent-erizer app or the Device
>>> 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.
>>> Contacts app with Picker UI) but why not just build the logic to
>>> Device APIs in to browsers if they're expected to talk to the low-
>>> Device APIs anyway? That's much easier (no Web Intents layer) and
>>> 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:47 UTC

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