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

> Definitely. Roughly, I think it would be:
>
>    X.prototype.tee() returns [branch1, branch2] where both are X instances.
>    X.prototype.tee() will lock this, making it no longer usable.
 >   Both returned branches will be unlocked, and you can separately call getReader() on them, with any arguments it might support (like { feedBuffers: true } for RBS). You can then read from them independently.

Ok, this is where I had different expectations.  I was thinking `branch1 === originalStream`, but here you are effectively consuming it.

Is it consumed because of the way this is written as an external function right now?  It seems like particular stream implementations could be smart enough to copy their internal details to produce a new branch.

In gecko we actually do something similar:

* Our streams can advertize they understand how to tee.  In that case the original stream's state is untouched.
* An external function attempts to use the tee interface if advertized, but if not, then consumes the original stream and produces two branches.  We have to do this because some things, like a file stream, cannot be tee'd without performing operations that might not be allowed in a content process.

The constraints that force us to use the external function in native don't seem to apply to streams exposed in js, though.  So I'm trying to understand why we can't require stream implementations to produce a tee without any observable state change in the original stream handle.

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