W3C home > Mailing lists > Public > public-device-apis-log@w3.org > February 2017

Re: [sensors] Batching API for sensor readings

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Thu, 23 Feb 2017 14:56:44 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-282013205-1487861803-sysbot+gh@w3.org>
Thanks for getting us started on this key conversation. 

> ```js
> let gyro = Gyroscope({frequency: 240});
> 
> const readingSize = 4; // tymestamp, x, y, z
> let buffer = Float64Array(readingSize * 4);
> gyro.start();
> gyro.collectLatestReadings(buffer);
> 
> function step(timestamp) {
>   // Now 'buffer' contains recorded readings.
>   gyro.collectLatestReadings(buffer); // Collect further.
>   window.requestAnimationFrame(step);
> }
> 
> window.requestAnimationFrame(step);
> ```

We want to make sure the API design doesn't force the implementation 
to preemptively store all intermediary samples in case 
`collectLatestReadings` gets called in the following animation frame.

I think that's what you're suggesting here, but that's unclear from 
the API name alone. It's something we need to express clearly through 
the API names. Worth checking other BYOB APIs on the Web for ideas 
here.

What the use cases point towards so far is an API where the consumer 
can:

1. Provide a buffer of the right size. Note it might be interesting to
 have a way to programmatically know the buffer size you need for a 
given number of readings, e.g.:
`let buffer = Float64Array(readingSize * gyro.getReadingSize());`
2. Know when the buffer has been updated.
3. Maybe know when the buffer is full (promise or event-based? During 
`rAF` or as soon as it's full?).
4. Possibly decide on a policy to handle what happens once the buffer 
is full (FIFO, FILO, throw, swap buffers, other?).
5. Read from the buffer.

> Also I would drop 'onchnage' event for motion sensors as it does not
 bring much benefits there and on the other hand it is called too 
often draining CPU and battery.

That requires removing them from `Sensor` too and thus creating an 
extra `NonMotionSensor` class inheriting from `Sensor`. Not 
necessarily a bad thing, but worth considering.

An other option would be to clearly distinguish between `polling` and 
`reporting` frequencies and throttle the latter to animation frame. We
 really need to understand what the use cases are for this, though.



-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/171#issuecomment-282013205 using
 your GitHub account
Received on Thursday, 23 February 2017 14:56:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:34:22 UTC