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

Glad to see this part getting spec'd, but I have a few questions:

1) Why is this defined as an external function instead of a method on the stream itself?  Wouldn't stream.tee() be more straightforward?  It would also let the stream implementation better specialize the tee() operation?  For example, I would think a stream that is implemented natively in C++ by the DOM layer might do things a bit differently, although semantically the same, from the exact steps here.

2) Should we define transferability first before adding the clone argument?  It seems that the structured clone for a transfer would need to be performed implicitly by the UA instead of via passing an arg like this.

3) Can you provide an example showing how SpeculativeTeeReadableByteStream() would be used?  I really don't understand that one from the given description.

I guess I'm thinking of how our native C++ stream does tee'ing when I read this.  Our nsPipe class internally maintains a single buffer.  Every tee'd stream then has its own cursor into that shared buffer.  The buffer is split up into segments and as the slowest reader finishes a segment it is free'd back to the allocator.  I think this is more efficient then duplicating buffers in two queues, etc.

Do you anticipate us being able to implement streams returned from DOM APIs using this kind of native code?

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