Re: [whatwg/streams] Fix makeReadableBackpressureByteSocketStream to drain all data (#504)

Thanks Adam for reviewing the meaning of the example seriously. Yeah, the adaptive stream idea doesn't make much sense for ordinal use cases basically.

As Adam said https://github.com/whatwg/streams/pull/504#issuecomment-237803327 and I said in https://github.com/whatwg/streams/pull/430#issuecomment-193877949 regarding Linux for example, it's safe to ask the kernel to buffer data.

To benefit from BYOB and also drain data from the source, the consumer should just prepare a large buffer to absorb all the fluctuation in download speed. The adaptive stream can add an additional option to it to have two-level strategy which is:
- the consumer would have a large buffer of X byte where X is kept chosen so that it's not too large (to keep average memory foot print small)
- the adaptive stream makes sure to drain data from the source when the data arrival speed it too fast accepting the cost of buffer allocation.

I tried to justify the need to drain data from the source, but don't have any good idea. Given that the POSIX socket API doesn't provide any method to directly control receive window size, buffer-in-JS may be useful to make sure to buffer large data to prepare for sudden slow-down of download. But this means that we try to always have some amount of data buffered, that is, we cannot benefit from BYOB. Buffering over X byte should just be temporary thing.

So, ... consumers for which the adaptive stream would be useful should have both the characteristics of WebSocket (push source) and BYOB style reading like POSIX read(2)...

-- 
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/pull/504#issuecomment-240020438