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

Specing out web intents for devices is interesting.  But it isn't
going anywhere.  I think we need to stay focused on the highest
priority use cases.  Simply accessing multiple remote sensors is a use
cases, but it is such a low priority it is laughable that we are
considering it.

As our charter states:

"""
Priority will be given to developing simple and consensual APIs,
leaving more complex features to future versions.
"""

Can we please keep the 'lets access all of these neat devices with web
intents' out of scope?  I'd be happy to start thinking about it when
we have parity with existing native APIs on most smartphones.

Doug




On Thu, Sep 13, 2012 at 6:44 AM, Niklas Widell
<niklas.widell@ericsson.com> wrote:
> 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 16:02:55 UTC