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

First, sorry for not having time to do an argument against async read() yesterday like I was planning. I'm taking care of lots of last-minute stuff before traveling. Today I will have time!! Although it seems @tyoshino has already started and I need to digest that a bit.

@yutakahirano

> By the way, in this option ReadableByteStream works differently from ReadableStream. As I wrote, "non-tricky" code can work with both, but the definition of trickiness is not given.
I think stating contract that all ReadableStream-like classes should ensure is very helpful. It should cover the user-facing APIs

I see what you mean. I started to try to cover those kinds of things in https://gist.github.com/domenic/65921459ef7a31ec2839#agnostic-consumers but it is not comprehensive. I agree it would be a good idea.

@tyoshino

> So, I think (C) requires that for pull(undefined) something similar to auto mode happens. Even if many many pull(undefined) calls are made, we keep (the total amount of outstanding I/O requests) + (total size of filled but not yet read()-ed buffers) under some high water mark.

Hmm. That seems possible, although perhaps complicated. I think I agree though.

@yutakahirano

> The current draft has Model section and many helpful notes such as ones in https://streams.spec.whatwg.org/#rs-prototype. They are good, but I think moving them into one section and promoting such notes to requirements which every ReadableStream-like class must satisfy will benefit custom stream developers and readable stream users.

Yes. That was kind of the idea of https://streams.spec.whatwg.org/#subclassing but that section has been kind of unmaintained and doesn't say very much that is helpful. I agree a more comprehensive list, and maybe a test suite (cf. #217, #264) would be good.


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