Re: [streams] First draft at tee algorithms, for critique (#302)

Here is a more broad take on the issue here, that maybe will be helpful.

I think we have simply run into an ordering issue with our design process. While designing `res.clone()`, we didn't have streams, and so we didn't try to think about how it would or would not be possible to do this kind of clone-while-leaving-unconsumed thing.

Now that we have streams, it becomes clear that clone-while-leaving-unconsumed is not a very natural thing to do with streams as specified. You can probably make it work, but doing so would be invasive to the stream implementation. Whereas, teeing is perfectly natural, and falls out of basic usage patterns of the public stream APIs.

The question at hand, I think, is whether we believe clone-while-leaving-unconsumed is a core use case for streams as a primitive. If it is, we should do appropriate re-design of stream internals and algorithms to support it. There are several possibilities here mentioned already: @tyoshino's three-tiered approach; the stream-wrapper idea; the hooking-and-unhooking underlying source path; or the all-streams-keep-track-of-clones-internally path.

But my perspective is that, given how natural teeing is (and not just here, but in other streaming or reactive or iterator APIs), and how unnatural clone-without-consuming is, it really isn't worth the added complexity. Basically, we goofed a bit by choosing `res.clone()` instead of `res.tee()`, which we did because of the order in which we designed and shipped APIs. And now we have to eat it, one way or the other. Having `.body` change seems like a pretty minor cost to pay, compared to all the other alternatives being discussed here.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/pull/302#issuecomment-83868073