Re: [streams] Support reading bytes into buffers allocated by user code on platforms where only async read is available (#253)

@tyoshino:

> I'm leaning toward making getReader() succeed only when there's no pending read(). Maybe I'd represent that (lockable or not) using some attribute on the stream. After thinking carefully, I don't think there's any big benefit to allow acquisition of lock while there's pending read(). @yutakahirano

That seems good to me. Or most anything else also seems good, since I guess the opinion changed a bit after your discussion with @tyoshino. I have come around to the perspective that we don't need to do anything fancy for reader semantics (like we currently do). It just needs to be straightforward and get the job done.

> We could reduce difference between ArrayBuffer and object by using Array for receiving objects. I'll also explore that path.

That sounds strange... did this go anywhere?

@yutakahirano:

> I now prefer async read to pull + sync read, because of the following reasons.

But it sounds like @tyoshino and you discussed this and it's back to pull + sync read?

> ArrayBuffer.transfer is not yet specified and we need a workaround for a while.

I don't think we do. The idea of transferring is well understood and exists in implementations, given that it is used for transferrables between workers and such. We might need to hand-wave a bit in the spec but I don't think it will be hard for implementers.

Stated another way, we don't need to wait for the public API known as `ArrayBuffer.transfer` to exist before we can use some kind of "ArrayBufferTransfer" abstract operation.

@tyoshino

Thanks for investigating (1). I also agree with your reasoning in (2), although they are subtle points. Maybe we should write them all up in an FAQ when the dust settles :).

On (5), I am still not comfortable with introducing a new abstraction. We would then have developer-facing byte source, stream, and underlying source.

Maybe it is OK if the byte source is actually just e.g. the Fetch Request or Response object. Then the API would look like `req.createAutoStream()` or `req.createManualFeedStream()` instead of `req.body`. (Or maybe shorter names, e.g. `req.stream()` and `req.manualFeedStream()`?). You could do similar things for File objects perhaps in a hypothetical stream-based file system API. (If this is what you had in mind in the first place I apologize for misunderstanding.)

(6) sounds really good. I would *love* to see you write up how this works with a few samples, since you seem to have a better grasp on it than me. In general we need to tackle this kind of WritableByteStream stuff soon.

----

**Action item:** What I am getting out of this (long) thread is that we are pretty comfortable with async `pull(buffer)` + sync `read()`. Is that right?

If so I want to change the spec back to `pull()` (no argument) on ReadableStream ASAP so that we can say that the public API has stabilized.

Is this good? Are we OK doing this? Or do we still think e.g. async read() might have a chance, or that pull(buffer) + sync read() is not settled yet enough to be sure? Please let me know :).

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