W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2013

Re: Device API organization - request for use cases/rationale

From: Tobie Langel <tobie@fb.com>
Date: Thu, 17 Jan 2013 14:47:51 +0000
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>, ext Rick Waldron <waldron.rick@gmail.com>
CC: "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, "public-device-apis public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <F9981AFB970564408FEB7DFCF62D4408436FFAD8@PRN-MBX01-4.TheFacebook.com>
On 1/17/13 3:24 PM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:

>[+cc Tobie]
>
>Hi Rick,
>
>On 16.1.2013, at 0.57, ext Rick Waldron wrote:
>
>[...]
>
>> The use cases are the same use cases that any form of DeviceFoo event
>>would havečthe ability to write browser based programs that interact
>>with device (mobile and desktop) sensors.
>
>The new design does not enable any new use cases? If so, it may be
>difficult to motivate implementors to change their implementations.

In my book, developer ergonomics is a good enough reason to warrant change.

>I can think of one use case that your proposal would address better than
>the current one: how to get the current proximity if the device is
>completely stationary. In your proposal the state could be explicitly set
>when the sensor object is instantiated. In the current design this is an
>implementation detail ("The definition of granularity i.e. how often the
>event is fired is left to the implementation.").

Absolutely. The current design completely mingles the notions of obtaining
the sensor's current value with that of reacting to change. The above
wording around granularity makes the ability to get an initial value in a
reasonable timeframe a quality of implementation issue, with no guarantee
that this value will ever be delivered if the device is kept stationary.
I'm worried we'll end-up with shipping devices having such issues unless
we change the specification accordingly.

--tobie
Received on Thursday, 17 January 2013 14:48:11 UTC

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