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

(Wow, when do you sleep @tyoshino!?)

Hmm yeah that is pretty interesting. I would probably use it :). I'm worried it might not be author-friendly though, even if it is good for implementers and gives a good mapping down to lower-level stuff.

Maybe it would help to more explicitly lay out the author use cases I am thinking of:

(1) Author who wants to operate on a generic stream without worrying about where it comes from or what's in it. In the current design they'll use `rs.pipeTo` in the simplest case and `rs.ready`/`rs.state`/`rs.read`, or maybe the reader versions of those, for more fine-grained control. In general this class of use cases is about generic compositionality---i.e., in the same way people write libraries and functions that are useful for all promises, we want people to be able to do so for all readable streams.

(2) Authors who are concerned about efficiency, at least at a high-level. Mainly, this would mean authors who want to avoid buffer copies, I think. For these authors I think a `rs.readInto` API, or something similar, is ideal.

(3) Authors who want direct control over the underlying sources as much as possible. These authors also presumably want *some* abstraction, otherwise they would not be using streams but instead would be manipulating the underlying source directly.

>From my perspective your ByteSource ideas are pretty nice for (3). However I feel like async read/readInto address (1) and (2) more nicely. And I think maybe async read/readInto addresses (3) when combined with a strategy (or perhaps with something more like your precise flow control). The main advantage though is that it keeps the number of APIs small so that we can all agree on a single one that many specs can start returning.

Note that having a single API doesn't necessarily mean having a single backing model. As you noted the existing design is very queue-based. I think what we've learned here is that queue-based works well for (1). However I don't think it works as well for (2). The current thinking is that ReadableByteStream and ReadableStream would share the same API so that (1) authors could use both interchangeably. Whereas (2) authors would use the extra `readInto` method, and would depend on ReadableByteStream *not* being backed by a queue-based model at all.

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