- From: Domenic Denicola <notifications@github.com>
- Date: Wed, 11 Feb 2015 09:08:08 -0800
- To: whatwg/streams <streams@noreply.github.com>
- Message-ID: <whatwg/streams/issues/253/73920026@github.com>
Well, that was kind of the entire point of ReadableByteStream, was to make it possible to do zero- or one-copy reads into user-allocated ArrayBuffers. For example you could do repeated readInto()s into the same array buffer that was pre-allocated to be the size of the file (determined by stat-ing) or response (determined by Content-Length). Async read was more of a strawman, and I'd rather not dive into it right now because it'd be a lot of spec churn. (I previously explored it [here](https://gist.github.com/domenic/197ae6fab8adc6890c7a#part-2-async-read), although at the time I wasn't aware of this particular case.) It's also less efficient for read(2)-style streams like HTTP streams, at least in theory. If we do decide to go that way then ... I'd feel bad about the churn at what seems like a pretty late stage, but it'd be OK I guess. But you guys had some interesting ideas for meshing the existing wait-for-ready-then-sync-read(Into) design with this use case, and I mainly wanted to see what those would look like in practice. --- Reply to this email directly or view it on GitHub: https://github.com/whatwg/streams/issues/253#issuecomment-73920026
Received on Wednesday, 11 February 2015 17:08:35 UTC