-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Propogate a drain event when no resume method is defined #2028
Conversation
If the readable stream must implement |
yes, and it's stream.Stream's job to implement that contract :) we'll have a much more comprehensive fix once we extend stream.Stream but that's not happening until 0.7. we should have done that before removing the current pause() and resume() semantics but ryan decided to move forward in 0.6. at the very least we need to un-break 0.6 drain. |
The streams API has So, if the readable stream does not have |
@koichik that's a great fix for 0.7 but in 0.6 i would prefer this because
this would be different if we had time to make the improvements that we want to stream.Stream but we haven't, in fact we've only removed functionality and broke things in stream.Stream in this release so i don't know why developers would suddenly start listening to us and using it as a base when we have nothing new to offer them. |
i'm getting a little frustrated. are we literally saying that, this used to work, now it doesn't, and the fix is to add documentation to tell people to write a stub method we used to have working? cause if it is, that's bullshit. |
@koichik I actually think @mikeal's right on this. The stream api is in a somewhat mixed up state, but there are real userland streams that worked in 0.4 and don't work in 0.6 as a result of removing the pause/resume propagation, because they relied on the default behavior to send the This change would make that work by passing a +1 for this change, if @mikeal can add some indentation and a semicolon to make it pass jslint ;) |
f'ing semicolons. |
Okay, I do not block this any longer. |
can we get some committer attention on this? |
Can one of the admins verify this patch? |
Fixed this by rewriting the entire streams interface (twice) |
Paused pipe() chains will never resume in 0.6 if a stream is in the chain that uses stream.Stream and doesn't define it's own resume() method.