Re: [sensors] Possibility to use "Readable Stream" as defined by the Streams API

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