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

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