- From: Adam Rice <notifications@github.com>
- Date: Sun, 15 Jan 2017 21:15:36 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 16 January 2017 05:16:10 UTC
An implementation of pipeTo() that doesn't make use of the queues in the streams is compliant with the standard. Consider ```javascript let writable = new WritableStream(burstySink); // [1] readable.pipeTo(writable); ``` versus ```javascript let writable = new WritableStream(burstySink, new CountQueuingStrategy(100)); // [2] readable.pipeTo(writable); ``` It is reasonable for content authors to expect that the extra queuing in [2] will stop the pipe from stalling due to the burstiness of the sink. However, user agents are permitted to treat these two cases as exactly the same. I think this hurts predictability of the platform. Similarly, adding a queue to a ReadableStream should be effective in mitigating a bursty or high-latency source. Two issues: 1. Balancing the requirement against "_WritableStreamDefaultWriterGetDesiredSize(writer) may be used to determine the flow rate heuristically, e.g. by delaying reads while it is judged to be "low" compared to the size of chunks that have been typically read._" is difficult. 2. Because of 1., phrasing it in a way that makes it testable is difficult. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/issues/653
Received on Monday, 16 January 2017 05:16:10 UTC