Re: [streams] Readable byte streams should support an internal queue (#353)

> Maybe it would help if we added, somewhere prominent, a note like:

Yes. I understand it helps. But I'm feeling that the all-in-one class approach would make things complicated.

> I don't think this is necessarily true. ...

It's fine to have a queue for convenience. But

> However, I think it might be OK if we say that this is rare enough ...

I was thinking as you described here.

> https://github.com/whatwg/streams/blob/bytestream/index.bs

Right. I was trying to build an all-in-one class in that branch. Sorry for confusing. I was trying but seeing difficulties in designing the class without much complexity.

Now it's almost done.
- Tee is not updated, yet.
- "pull" semantics is the same as ReadableByteStream if the underlying byte source doesn't have "pullInto" on it. If the underlying byte source has "pullInto" on it, "pull" semantics will be different from one of ReadableByteStream.
    - Once the underlying byte source receives "pullInto" (i.e. there was no view queued in [[queue]]), it must respond to it by calling controller.respond(). Calling controller.enqueue() fails.
    - Otherwise, i.e. received only "pull" or there's no pending read, the underlying byte source may call controller.enqueue().
    - When a new read (either BYOB or non-BYOB) is made on a stream with non-empty [[queue]], the reads would be fulfilled by consuming bytes in [[queue]].
- When non-1 element size TypedArray is provided to a BYOB reader, it doesn't fulfill until at least one element is filled.
- If controller.close() is called with a partially filled non-1 element sized TypedArray left in [[pendingViews]], the stream gets errored.

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