Re: [streams] Add ReadableByteStream definition (#343)

> I am a bit confused by the controller + underlying source model here. From what I can see, the idea is that pull() is called on each read, and each time it is called, you can call c.resolve(chunk) once. Is that the idea?

Right. `pull()` is just a notification of `read()`. The user can call `c.resolve(chunk)` at any time.

The readable byte stream is kept as minimum as possible but able to represent invariants, constraints, semantics of the API surface completely. The controller is not designed considering usability. Maybe, I should not have added the controller API but only define abstract operations to manipulate the readable byte stream's state.

> I thought though that ReadableByteStream was going to need an internal queue as well. Because what if someone doesn't read for a long time, and the kernel buffer starts getting full? Do we make underlying byte source implementers do their own buffering to handle that case?

The latter.

> Also I know we had a discussion in person which concluded that c.resolve(chunk) was better than return chunk or return promiseForChunk, mainly having to do with cancelation. Can you help remind me why that was important?

You were imagining some example implementation of the underlying source where you're trying to encapsulate an async API that returns a promise. And you said that we basically want to return the promise (as-is or after some transform) than converting it to call to `c.resolve()`, etc.

> The resolve name is probably not the best but we can figure it out later. (Maybe it is fine but it feels like it's too tied to promise terminology, whereas promises are kind of more an implementation detail, that the underlying byte source should not need to know about.)

Was using fulfill. Fulfill might be better as the streams are supposed to be enqueued non-promise values?

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/343#issuecomment-98040533