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

> 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 see. So we may want to make it clear that this is still undergoing revision. But the public API will be OK.

>> Do we make underlying byte source implementers do their own buffering to handle that case?

> The latter.

This seems sad. Also I think we wanted to support buffering (in the non-BYOB case) to avoid "jitter"? Hmm.

> 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.

Right, I remember the argument for using promises instead of `c.resolve` :). But I forget the argument for using `c.resolve` instead of promises. Sorry, I guess I was a bit unclear what my question was there.

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

I meant more pick a verb that has nothing to do with promises. Looking through a thesaurus, here are some random options: answer, conclude, fill, finish, satisfy, produce, complete, finalize, respond.

---

Anyway, let's start merging stuff and iterating on it in further PRs and issues, using #300 as the central tracking issue once the dust settles. I think we should squash everything into a single commit that does the following:

- Remove ReadableByteStream reference implementation and tests
- Contains the contents of both this PR and #351

If this sounds good to you, let me know. If you are ready to go to sleep then I will do it (and file a few follow-up issues/PRs). Or if you want to take care of some other stuff first before we merge then that's good too :).

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