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

@domenic,

>> (A) ... There is no pulling mode.

> Minor point: there is no consumer-initiated pulling, I agree. But a non-byte stream implementation could "pull" ahead of time if it wanted, to make future calls to read() fulfill immediately.

Yeah, I thought about the consumer-facing pull, i.e. pending read in this option.

>> @domenic, is your "async pull + sync read" (B) or (C)?

> It was similar to (C). However, I did not envision an auto-mode. Instead, it was always manual-mode, but if you omitted the parameter to pull() it would auto-allocate a buffer for you. I am not sure about the value of auto-mode if we can make manual-mode ergonomic in this way.

I see.
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 imagine @tyoshino's concern 

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

can be mitigated then.

The contract will be stated mainly in a natural language (e.g. English, not JS) and both ReadableStream and ReadableByteStream must satisfy it.

What do you think? Is it possible?


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

Received on Thursday, 5 March 2015 06:28:15 UTC