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

> As you know I would prefer to have similar ...

The operationStream branch now contains several suggestions but they are independent from each other. Operation concept was introduced for unifying APIs into single one. OperationStatus was introduced to enable synchronous/asynchronous hybrid consuming experimentally.

For pull + sync read() + write() + readDisposed(), OperationStatus is unnecessary.

>From operationStream, I'd like to incorporate:
- queue / stream separation
- revised set of promises
- revised preconditions for getReader() / getWriter() and release()

Regarding Operation, as I said somewhere:
- current WritableStream.write() is representing operation result, and UnderlyingSource.write() is required to acknowledge each write
- ReadableStream.read() is representing value, and UnderlyingSink.enqueue() enqueues a value and forget. When cancelling the stream, the consumer code cannot tell the source which chunk actually caused the error.

This asymmetry still looks a little odd. I don't insist that we should make read() return Operation, but do we need to keep each write() return a promise for returning the result of individual write()? Currently I don't have any practical rationale to request this change but wanna discuss carefully to get some agreement.

> For the writable side it might make more sense. The return value of write() is not always used very much anyway, so if it becomes a bit more work to check it then that is OK.

Thanks. As I wrote above, I'm not sure what's the best.

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

Received on Tuesday, 3 March 2015 18:16:55 UTC