Re: [streams] Prototyping several changes for better support for reading bytes (#287)

> Does this affect public API (either for stream creators or users)?

Creators are affected. Users are not affected.

> I notice the new comments at the top of the file (which are extremely helpful) have slightly different underlying sink/source designs. Instead of being based on strategy they give more direct control---which is probably a good change. Is that part of queue / stream separation?

Yes, that's exactly what I meant by queue / stream separation. Maybe there're still sources / sinks that really want to use a queue. We can provide some additional helper classes for them. I.e.

- ThinWritableStream + QueueSink === Current WritableStream
  - QueueSink would have API similar to current WritableStream's underlying sink
- ThinReadableStream + QueueSource === Current ReadableStream
  - QueueSource would have API similar to current ReadableStream's underlying source

Thin.* are used by sources / sink which needs freedom.

> > revised set of promises

> I am not sure these are an improvement, personally. What was the motivation?

After bunch of changes, I'm not so inclined to push this. They were for some simplification. I don't remember so much... I've almost reverted them for now.

> The addition of the "locked" state is hopefully not too annoying. Prototyping will help confirm. But in general (I know I'm repeating myself, sorry) I am in favor of changing the preconditions in ways that make things more straightforward.

We've almost reached agreement that it's fine as far as we can hide internal state and forbid operations on the stream while it's locked. Then, prohibiting everything should be fine. Yes, we need to be careful not to decrease usability. But maybe ok...

On the latest commit, I've prototyped byte source / stream (reader) separation as discussed around https://github.com/whatwg/streams/issues/253#issuecomment-76998452.

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