After several conversations about this I have identified one thing we lose with
this change.
Because the current implementation makes streams start emitting data right
after creation and could start doing so at any time after nextTick() it's
required that all streams be connected within a single tick.
In request, and other streams, we make the assumption that all stream behavior
was setup in a single tick, which is how this works:
```
request.get(url, function (e, resp, body) {})
fs.createReadStream(file).pipe(request.put(url))
request.get(url).pipe(fs.createWriteStream(file))
```
I need to know before I start the underlying http client if this has a source
and/or a destination stream. If there is no source stream I must call end() on
the underlying http client. Now, we do get out of needing to know the
destination stream ahead of time **if** i have a way to know that I shouldn't
be buffering the data for a callback. I think i could do this by simply
removing a feature i used to have where that callback became a callback on
"response" and did not include buffered data.
The new stream style rids us of the pause/resume dance but it also means that a
stream can be created and just hang out for many cycles before getting piped to
something else. That means we lose an assumption we used to have and that we
have spent some time building on.
Now, it's very uncommon that you would create a stream and then pipe **to** it
some number of cycles later. But, over time I think that people will be used to
the "magic" of these new streams that can be created and piped around whenever
and will step on this.
This is not meant to derail or stop any of the changes proposed, it's simply an
assumption we used to make and have come to rely on that cannot be polyfilled
and will break whenever this gets released.
-Mikeal
On Jul 26, 2012, at July 26, 20129:57 PM, Isaac Schlueter <i...@izs.me> wrote:
> I think the real problem is with readable streams. Writable streams
> are pretty easy to implement, but the readable side is unnecessarily
> difficult and too easy to get wrong.
>
> Here's a proposal in code: https://github.com/isaacs/readable-stream
>
> The readme explains the position, and the implementation makes it easy
> to play around with. A base class and a fs readable stream class are
> provided. Note that Readable.pipe() is very short and simple :)
>
>
> On Sun, Jul 15, 2012 at 7:25 PM, Dominic Tarr <dominic.t...@gmail.com> wrote:
>> I've been writing and using a lot of streams lately,
>> and have some proposals for some small changes to node's streams.
>>
>> https://gist.github.com/3117184
>>
>> in some parts it's a tightening up on expected behaviour,
>> in others it's a few small changes to Stream#pipe.
>>
>> cheers, Dominic
