Re: [sensors] Add solution for one-shot readings

re @darobin's 
[comment](https://github.com/w3c/sensors/issues/88#issuecomment-193281097):

> @tobie I've been out of the loop for a while, but is the `rAF` 
example realistic (and fundamental)?

Yeah, it seems like a common use case for all the device orientation 
stuff.

> I'm presuming that it does not involve synchronous reading, so 
you're just getting whatever cached value there is.

Yup. Basically it's a convenience for doing something like:

```js
var currentReading = null;
sensor.onreading = event => currentReading = event.reading;
requestAnimationFrame(function frame() {
    console.log(currentReading);
    requestAnimationFrame(frame);
});
```

Are you suggesting that by abandoning this feature altogether we could
 instead tie permission request plus starting to poll the sensor to 
adding a listener? I thought another key design principle of the 
platform was that listening to events shouldn't cause side effects. 
/cc @annevk 

>Regarding more advanced primitives, well, you gotta keep the pressure
 up :)

heh!

>Also: you can reproduce the same behaviour with `EventTarget` (albeit
 more verbosely).

Well, that's a really interesting question. Afaik, there's no real way
 to tie the event loop and the sensor polling together, so I'm not 
sure you could actually prevent the sensor from being polled a second 
time.

> Other than that, I wonder if you're not mixing the caching behaviour
 into the sensor too much?

Possibly, but some of it comes from requirements from concrete sensors
 (and have valid battery saving implications).

> You have pretty granular caching needs,

Well, not _really_. You want access to the latest reading and 
eventually access to a previous reading if you don't need super fresh 
data (i.e. geolocation might be happy with a reading that's a few 
seconds old in some cases).

> it strikes me as strange to have them built into the sensor itself.

That I buy for the current sensor reading. If you're talking about a 
data point that's seconds to minutes older, you want this to sit at a 
lower level (e.g. in the sensor hub itself), so as to be cross-origin 
and even cross-apps.

> By splitting up the responsibility you can design both separately; 
you can also think about cases in which you would make the cache 
user-replaceable so that devs could fine-tune the caching behaviour 
they want.

I don't think this method actually prevents API consumers to bring 
their own cache. It's just a convenience for the most common case.

-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/88#issuecomment-194834219 using 
your GitHub account

Received on Thursday, 10 March 2016 13:07:36 UTC