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

> 1) Yes, I was just starting with an algorithm other specs could reference, but it'd make great sense to define ReadableStream.prototype.tee() that returns TeeReadableStream(this) and ReadableByteStream.prototype.tee() that returns TeeReadableByteStream(this).

Do you mean "ReadableByteStream.prototype.tee() then returns SpeculativeTeeReadableByteStream(this)"?  So SpeculativeTeeReadableByteStream() conforms to the same semantics at TeeReadableStream()?

I think its the word "speculative" that's throwing me off here.

Defining the contract that all tee() functions must conform to separately might help me.  I like to see interface separate from implementation, etc.

> 2) Hmm, I don't quite follow this. Could you explain more? In particular, I don't think we want to allow transferring the contents of a stream---the entire point here is to actually produce two copies, such that both can be operated on in separate threads at the same time without affecting each other.

Well if you do `postMessage(stream)`, the transfer is going to have to structure clone the contents of the stream during the transfer.  Even if you tee() first and then do `postMessage(branch2)`, the transfer will still have to structure clone again since branch2 is still accessible in the original JS context.  It seems the structure clone must be embedded in the postMessage() transfer to me.  Doing it here is duplicative and kind of wasteful.

The one case I see where the clone argument makes sense for single JS context like this is if the ReadableStream chunks are mutable.  In that case branch1 could read chunks, modify them, and then branch2 would see the modifications when it later reads.  Doing the clone would avoid that mutation from being observed in branch2.

> Hmm, very interesting. It sounds like the tee'd streams are not really of the same "type" as the original stream? That is, they are not very general purpose, but instead there's a cooperation between the branches and the original, where the branches largely consist of a cursor and not much else?

Well, no.  From the consumers point of view they are exactly the same as the original.  The consumer just sees a stream interface with a read() method.  For this nsPipe case the original stream was originally just a cursor with an underlying buffer; the buffer just wasn't shared yet.  Add'ing another branch to the nsPipe doesn't effect the original stream at all.

Of course, this is a purely byte stream, so maybe it only applies to ReadableByteStream.

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