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 15:57:25 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-282032472-1487865444-sysbot+gh@w3.org>
> > 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 thought that if the actual amount of readings exceeds the given 
buffer capacity, the older records will be dropped and newer will be 
still added, so that buffer contains always the latest recorded 
readings

That's not what I meant. Let me try and clarify.

The API name suggested above gives the impression you'll be able to 
fill up the buffer with existing readings pre-stored somewhere and 
read from it in the same event turn.

***

> I thought that if the actual amount of readings exceeds the given 
buffer capacity, the older records will be dropped and newer will be 
still added, so that buffer contains always the latest recorded 
readings

That said, that wouldn't meet the Navisens use case for which dropping
 samples is a deal breaker.



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

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