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

On Thu, Jan 17, 2013 at 9:47 AM, Tobie Langel <tobie@fb.com> wrote:

> 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.
>

I would've written nearly the same responses, but Tobie got there
first—thanks Tobie!

To give an example of a use case afforded by the proposal Tobie and I are
converging on:


var prox = new Sensor.Proximity();

console.log(prox.cm);

// prints out whatever the current distance reading is.
// I can access this anytime, anywhere in my program and it will
// give me the current distance in cm.
// Of course I can also add an event listener if I want

vs.

var cm;

window.ondeviceproximity = function( event ) {
   // I can't get a value from "cm" until the event is dispatched.
   // I also now have free-vars in my program.
   cm = event.cm;
};

// No point in logging the initial value, it will be undefined until
// after the first "ondeviceproximity" is dispatched



RE: identity by attribute: Like any seasoned software engineer, I'd much
prefer instance object identity over some mutable string or number id
attribute, when the former is clearly more appropriate. Bolting on junk
"fixes" is a spec smell.

Forget my argument about device sensor quantities, that was me trying to
live up to some belief that I needed to show "numbers" to make my case—it
should be enough to say that the direction is just wrong because I know, as
a professional software engineer who earns a living writing JavaScript
everyday, that it's wrong. I know as someone who's designed and continues
to support JavaScript APIs for device sensor programming. I also know as
someone who has written device sensor programs in a handful of other
languages. I understand that an implementor or two has invested some work
into this already and I can appreciate and sympathize—I've spent months and
months working on similar APIs, but I still think that doing it the
JavaScript way (constructors, prototypes, etc) is the best way (considering
it will be implemented for use in JavaScript applications).

I'm asking you to _please_ _just_ _listen_ to me, to Tobie Langel, to
Marcos Caceres, to Paul Bakaus, to Brian Leroux and everyone else that has
spoken up over the device API threads.

Thanks.

Rick



>
> --tobie
>
>