Re: [streams] How will ReadableByteStream work with seekable resources? (#253)

Sorry for the delay on this. I had a hard time paging it back in.

Unfortunately I think it is the first case:

> - accepts a buffer
> - based on the size of the given buffer, controls how much data it pulls from the source

This can be seen by looking at e.g. Win32 [ReadFile](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365467%28v=vs.85%29.aspx) or Unix [fread](http://man7.org/linux/man-pages/man3/fwrite.3.html) and [pread](http://man7.org/linux/man-pages/man2/pwrite.2.html).

> In what form can we provide readIntoAsync() together with read()? To allow sync read() we have on the ReadableStream, we need to pull data from the source at least when we're in the "waiting" state. Otherwise, we never enter "readable" state. But this spoils the readIntoAsync()'s benefit. We'll have some data already pulled (to serve for read() user) when readIntoAsync() is called.

Yes, I agree, this is a problem. The only thing I can think of immediately is to remove sync read() and the whole waiting/readable state transition :(. Assuming that we would carry that over to ReadableStream that would be a lot of churn this late in the game which is frustrating. Maybe we can think of a better solution. E.g. maybe SeekableReadableByteStream only matches ReadableStream in its pipeTo API? :-/

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