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

(A) looks reasonable landing point though I miss the sync read() interface we've been developing.

About (B), I agree that it's basically the same as (A). For object streams, it's meaningless to ask users to call pull()/wait(). I think we should avoid that and just choose (A). (B) keeps the sync read() interface but the badness of meaningless pull()/wait() for object streams beats the benefits in my mind.

(C) is great ... It made one who doesn't know bring-your-own-buffer reading functionality to call wait() to invoke pull-with-auto-allocate without realizing that he/she is pulling by wait() which he/she called in order to obtain readyPromise ... Yes, I understand that this is intelligent. But, ... hmmm

(D) is what I originally had in my mind when I started saying "feed". (D) is now implemented on operationStream branch. https://github.com/whatwg/streams/tree/b79a7aff04e306f62a74511833812c59487004a0/reference-implementation/lib/experimental
For object streams, we keep using the sync read(). No need to call pull(). Maybe that's the major benefit of (D). Instead of pull(), I'd like to add window setter/getter to control high water mark. I don't think everyone feels comfortable when they see how the manual pull works. This is an approach to attempt to do the best on object stream / auto mode than valuing reduction of usage difference between manual and auto.

I think there's (D)-ii where we use ready + sync read (for auto mode) and async read (for manual mode). (D) is an approach where we give up reduction of usage difference. For manual mode, we can choose any API.

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