{"action":"created","issue":{"url":"https://api.github.com/repos/iojs/readable-stream/issues/99","labels_url":"https://api.github.com/repos/iojs/readable-stream/issues/99/labels{/name}","comments_url":"https://api.github.com/repos/iojs/readable-stream/issues/99/comments","events_url":"https://api.github.com/repos/iojs/readable-stream/issues/99/events","html_url":"https://github.com/iojs/readable-stream/issues/99","id":54626427,"number":99,"title":"Proposal: Deprecate implicit flowing of stream via on('data')","user":{"login":"chrisdickinson","id":37303,"avatar_url":"https://avatars.githubusercontent.com/u/37303?v=3","gravatar_id":"","url":"https://api.github.com/users/chrisdickinson","html_url":"https://github.com/chrisdickinson","followers_url":"https://api.github.com/users/chrisdickinson/followers","following_url":"https://api.github.com/users/chrisdickinson/following{/other_user}","gists_url":"https://api.github.com/users/chrisdickinson/gists{/gist_id}","starred_url":"https://api.github.com/users/chrisdickinson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/chrisdickinson/subscriptions","organizations_url":"https://api.github.com/users/chrisdickinson/orgs","repos_url":"https://api.github.com/users/chrisdickinson/repos","events_url":"https://api.github.com/users/chrisdickinson/events{/privacy}","received_events_url":"https://api.github.com/users/chrisdickinson/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/iojs/readable-stream/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":8,"created_at":"2015-01-16T21:21:36Z","updated_at":"2015-01-19T20:54:23Z","closed_at":null,"body":"Via a conversation in [this issue](https://github.com/iojs/io.js/pull/451#issuecomment-70162263) (towards the bottom of my linked comment.)\r\n\r\nI propose that we deprecate (with the intent of eliminating) the implicit flowing of streams via `.on('data')`, opting instead to encourage users to use `.resume()` and `.pipe()`. It breaks the EventEmitter API contract to have side-effects based on adding a listener, which surprises users. While there are ways around it for normal listeners (namely `EventEmitter.prototype.on.call(stream, 'data', fn)`), they're not natural, and EventEmitter APIs that call `.on` will still trigger side-effect-ful behavior (for example, `.once`).\r\n\r\n## Benefits\r\n\r\n* Streams would only have two states, flowing and paused, instead of the three they have currently (the *undocumented* third state, \"undefined\"). \r\n* Streams may be `.pause()`'d and `.resume()`'d without losing access to the third \"undefined\" state.\r\n\r\n## Obstacles\r\n\r\n* `Readable#pipe` could no longer rely on the implicit flowing behavior of `.on('data')` to start the stream (so we would likely have to call `src.resume()`).\r\n* `streams1.Stream#pipe` is entirely separate from `Readable#pipe. This may or may not prove to be a problem since streams1 streams implicitly flowed to begin with.\r\n* Messaging/education – we don't want people to get streamsN fatigue.\r\n* In general in io.js/node development, it's hard to tell how many packages will break due to a given change, or even to get a read on the number of users of a given feature.\r\n\r\n## Questions\r\n\r\n* Is the simplification of the streams state machine worth the effort (for us as well as for end users)?\r\n* In general, is making the API more explicit desirable? If so, what would it look like if `.resume()` was the only method to start flowing a stream? I.E., if this class of change represents \"a good thing,\" why not take it even further?\r\n\r\n/cc @iojs/streams"},"comment":{"url":"https://api.github.com/repos/iojs/readable-stream/issues/comments/70558813","html_url":"https://github.com/iojs/readable-stream/issues/99#issuecomment-70558813","issue_url":"https://api.github.com/repos/iojs/readable-stream/issues/99","id":70558813,"user":{"login":"sonewman","id":2377664,"avatar_url":"https://avatars.githubusercontent.com/u/2377664?v=3","gravatar_id":"","url":"https://api.github.com/users/sonewman","html_url":"https://github.com/sonewman","followers_url":"https://api.github.com/users/sonewman/followers","following_url":"https://api.github.com/users/sonewman/following{/other_user}","gists_url":"https://api.github.com/users/sonewman/gists{/gist_id}","starred_url":"https://api.github.com/users/sonewman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sonewman/subscriptions","organizations_url":"https://api.github.com/users/sonewman/orgs","repos_url":"https://api.github.com/users/sonewman/repos","events_url":"https://api.github.com/users/sonewman/events{/privacy}","received_events_url":"https://api.github.com/users/sonewman/received_events","type":"User","site_admin":false},"created_at":"2015-01-19T20:54:23Z","updated_at":"2015-01-19T20:54:23Z","body":"@isaacs I like the idea of meditating on streams *\"be like water\"...*\r\n\r\nanyway, I think everything you say is right. We need a plan and collaborative vision, the closes thing so far IMO was @mikeal's comment in issue #97 \r\n> Any differences between io.js streams and WHATWG streams will have to be reconciled at some point. By that I do not mean that io.js streams will become WHATWG streams or vice versa, but that we need to iron out any irreconcilable differences while WHATWG streams are being standardized so that either io.js streams become a compatibility API between legacy streams and WHATWG stream or transpilers like browserify can solve this in the future.\r\n\r\n> The thing I'm most worried about is a situation similar to what we have with Buffer vs TypedArray.\r\n\r\nWe should absolutely explore all possibilities, since the solution is likely to be the best bits of everything.\r\n\r\nWould could also do with (a brief) yet concise technical specification of a stream (this could be derived from WHATWG). Just to be clear on our objective. I mean right now it's possible to do interesting things with the streams we have, which is not always obvious to the new or experienced user.\r\n\r\nLots of people are still using node v0.10.x (due to corporation confidence constraints - I know this well) and may not be using the readable-streams module v1.1.13. Therefore not even reaping the benefits of streams3.\r\n\r\nThere are obviously lots of great resources out there for using streams, but are usually based on streams2 since it has been the de facto.\r\n\r\n@chrisdickinson I still think you should definitely continue your explorations and please keep posting ideas."}}