Re: [streams] ReadableStream.getReader name is a bit misleading (#308)

Per my habit, I will reason by analogy to established patterns from which to project names.

What happens between when you release a reader and get/acquire/take/retain a new one? I am going to assume for the sake of argument that the stream’s buffer accumulates and no information is lost.

I suspect that Stream and Reader correspond to the same conceptual entity, so there’s API funny-business going on. Stream and Reader both correspond to sources of data that can have only one consumer (unicast). They differ in that the Stream provides no opinions about how to consume it and alternately vends out to a Reader and instead guarantees that it will only vend readability out to a single consumer at a given time.

I say "readable" loosely because of the shared distinction between "Iterable" and "Iterator", "Observable" and "Observer", "Readable" and "Reader". The Verbable has a verb, e.g., [Symbol.verbable]() or simply verb() that returns a Verber. A Verbable can be multicast or unicast, and a Verber is strictly unicast. I feel a slight preference toward favoring multicast for -ables. Acceptable semantics for different kinds of Readable would include: broadcast (multiple consumers see a contiguous portion of the total stream and all concurrent consumers push back on the producer together), multicast (multiple consumers each start from the beginning, so the whole stream must be accumulated/cached), unicast (multiple consumers greedily consume non-overlapping portions of the whole stream).

Stream and Reader have a funny relationship. The Stream seeks to ensure unicast consumption by vending to a single Reader, but ultimately a single Reader could be shared by multiple consumers and, in the case of distributing work to multiple consumers, is actually a useful feature.

My interpretation is that Stream exists for possibly two reasons. On one hand, it is a convenient object for providing different consumer methods if readers turn out to be insufficient. On the other, it provides a point where the underlying fetch API can vend readability to user space and revoke the capability if the user gives it back to the system, so it can bypass userland piping. Strikes me that this is superfluous since a Reader might have directly revokable use of its read() method, or its forEach, map, reduce, all, done, or destroy methods if any of those come to be. Many of these methods could take a lock out on the underlying reader, but I suspect that is unnecessary. If the system decides to consume the stream, it can just starve userland.

Conclusion: getReader does not need a name. Have Reader assimilate Stream.

Of course, I probably missed something important.

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