- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Mar 2017 11:01:15 +0000
- To: public-device-apis-log@w3.org
> We can. Than we'll always provide 4 latest readings, but if frame rate goes down for some reason and for example 6 readings are missed (i.e. not propagated) than only latest four will be delivered and previous two lost. Is it acceptable? Well, that's an interesting tradeoff I frankly don't have a good answer to until we have clearer use cases and requirements. How large can such a buffer be? i.e. can you get some extra space to account for say the 95% percentile of frame delays? *** Going back to one of your previous comments, I agree we might also want another API that trades off latency over integrity, perhaps for bigger sample sets. The requirements I'm roughly seeing so far are (take those with a grain of salt for now): 1. latest sample, low latency. 2. latest few samples, low latency, ok to loose some samples. 3. batch of samples, important not to loose any, latency not so much of an issue. I'm wondering whether (1) and (2) could be combined in a single API, though (2) requires you somehow integrate timestamps in the output which (1) can (possibly) handle differently. -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/171#issuecomment-288044722 using your GitHub account
Received on Tuesday, 21 March 2017 11:01:21 UTC