- From: Zoltan Kis via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Nov 2015 11:56:56 +0000
- To: public-device-apis@w3.org
A few comments post facts. This API deliberately [exposes high level sensors only](https://w3c.github.io/sensors/#high-vs-low-level). So in general it is fine to apply algorithms on the data. When it comes to pressure, usually it is fine to lose real-time data if the client cannot handle it, but the spec needs to be clear about the requirements concerning UA resources. Depending on the type of data there are flow control techniques to comply with the limitations of the client, much like adaptive codecs are doing to handle network limitations. In general, a consumer (client) should be able to specify a desired maximum sampling rate, a buffer size, and a policy. We want the UA take care of the rest, and just provide a notification mechanism for available data. The preferred policy tells what set of means is available for the sender to control. For instance with EKG sampling policy, you are fine with losing resolution, if the range (maximum and minimum value samples) is preserved. In other cases, any samples can be removed, even full chunks, at it is more important to remain in sync than to transmit all real-time data. For buffering, one policy could be to just slide the buffer forward in time by one chunk. Another is to add a mechanism to preserve the first sample and drop more and more samples in the given window, making resolution less and less, until a given threshold when the buffer slides. If not supported by HW, this can be implemented with multiple buffers interleaved on reads, and dropping them sequentially (until slide). When it comes to clients expressing preferences, the server should reply with the ones it could meet (the usual negotiation). To me it seems the current spec addresses the frequency and (indirectly) the buffer issues, and could add sampling and buffering policies support later. Since all the above are meant to relax the pressure of streams, I agree with Tobie's conclusion to not jump to streams yet. -- GitHub Notif of comment by zolkis See https://github.com/w3c/sensors/issues/70#issuecomment-156084642
Received on Thursday, 12 November 2015 11:56:58 UTC