[streams] Maybe giving async readInto (and read?) another shot (#290)

While working through https://gist.github.com/domenic/65921459ef7a31ec2839 for #289 I was a bit worried by the concerns mentioned in the section "Reading a byte stream into ArrayBuffers" about memory fragmentation. I don't think there's a good way to address them without a true readInto-style API. But previously we discussed how this would have to take the form `readInto(sourceAB, offset, count) -> Promise<{ bytesRead, newAB }>` due to the transfer restrictions, and how this is ugly.

I have a slight reformulation of it that might not be 100% ugly. It hinges on [a very old discussion](https://gist.github.com/domenic/197ae6fab8adc6890c7a#part-2-async-read) I had with myself, about `EOS` versus `{ value, done }` design for async read(). My thoughts have always been that `{ value, done }` is theoretically better, but practically more annoying, and so I picked EOS.

But, if we go back to `{ value, done }` for async read(), then I think it the async readInto signature proposed above seems less crazy. Picking nice variable names, we could have

```
rbs.read(bytesDesired) -> Promise<{ value: ArrayBuffer, done: boolean }>
rbs.readInto(sourceAB, offset, bytesDesired) -> Promise<{ value: ArrayBuffer, done: boolean, bytesRead: number }>
```

Here, given `rbs.readInto(source, 0, 1024).then(result => ...)`, we would have that `result.value` is a transfer of `source`.

What do people think?

---

Here is an alternative. We could go with the design in https://gist.github.com/domenic/65921459ef7a31ec2839 (async `pull(ab_opt)` + sync `read()`). But, we could entirely separately add async readInto, ugliness and all, to ReadableByteStreams. We wouldn't make read() async at all---neither { value, done } nor EOS. We would just add this separate async readInto method for use cases that want to avoid potential memory fragmentation and get the best level of control that I think we can give in JS.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/290

Received on Saturday, 28 February 2015 00:04:36 UTC