isaacs mentioned to me in irc that he wanted to implement a
ReadableStream, but leave Stream exactly as it was.
so, have two types of stream.
there is another thing this would break, it would be impossible to
stream a .read() based ReadableStream to multiple destinations...
Although, if regular Streams still exist, then you'll still have that
if you need it.
On Sat, Jul 28, 2012 at 7:03 AM, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> 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
>
