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

> In Blink, we don't have it yet. 

Hmm OK. I thought it would just be a natural extension of the cross-worker transfer (from structured clone). But I can understand if not. Do you think there's a potential theoretical problem or is it just the practical issue of when work gets done?

> Request, Response, etc. would have stream factory methods.

OK. I will try to think through this idea more then.

> From operationStream, I'd like to incorporate:

I will continue this over on the operation stream thread.

> This asymmetry still looks a little odd.

We could make enqueue() return a promise that isn't fulfilled until the corresponding read() is called. But I am not sure what the use case is.

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

It seems pretty desirable to know if a chunk has been uploaded or written to a file. For example that's how you would do upload progress (in the case of a fast source and slow sink).

It's OK though IMO if write() returns some kind of structure like `{ ack(), finished }` instead of just returning a promise directly. Unlike read(), where the return value is always important, for write it is only used sometimes, and other times just using `ws.closed` is enough.

> If write() may return after writing only partial data, write() needs to return how many bytes have been written.

I don't think write() should return after writing only partial data. But maybe this is because of my ignorance of the native APIs involved. I will go do some reading on them to make sure that what I envision fits with them.

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