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

Still thinking, but I started feeling that `.readInto()` shouldn't be on the `ReadableByteStream` but rather be a part of the pulling tools such as `.feedArrayBuffer()`. Current `ReadableStream` is a nicely-simple and easy-to-understand queue representer. It may receive pulling signal implicitly via `.read()` call, but except that point, it's just a queue. Maybe we should decouple pulling methods/attributes when designing custom pulling tool than complicating the simple ReadableStream interface more.

For POSIX socket,

```es6
class ByteSource {
  // true when the socket has any data for read.
  get pullable()
  // Returns the associated ReadableStream.
  get stream()
  // Returns a promise that fulfills when pullable value changes from
  // one on the watch() call.
  watch()
  // Calls read(2) on the given Uint8Array. Queues a new Uint8Array
  // representing the written region to the associated ReadableStream.
  readInto(abv)
}
```

For blocking or async I/O interfaces which takes a buffer on invocation,

```es6
class ByteSource {
  // Returns the number of bytes being pulled from the I/O but not finished.
  get bytesPulling()
  // Returns the number of bytes queued on the associated ReadableStream.
  get bytesReadable()
  // Returns the associated ReadableStream.
  get stream()
  // Returns a promise that fulfills when
  watch()
  // Kicks the async I/O with the given Uint8Array. Queues a new Uint8Array
  // representing the written region to the associated ReadableStream
  // on completion.
  pull(abv)
}
```

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