Callback for async _read

[calvinmetcalf]

Idea: pass a second argument to _read that signals to stream that the function is done producing data and should be called again if more data is needed. In other words instead of having to look at the response from this push.

For certain types of data this is a much better setup (for instance finding all the files in a directory and it's children) and is in line with how whatwg streams work iirc.

Doing it backwards compatibly there are a couple paths:

• use function length and make it async if the length is 2
• give it a new name (asyncRead? pull?)
• make it an option (async:true)

[chrisdickinson]

The problem I see with giving _read a callback is that it complicates the logic in the synchronous case: every read that results in a _read would have to create a function + closure and manually track the synchronicity of the function call to ensure that we don't blow out the stack on flow.

[kanongil]

This is not a new idea, and for a long time this was the way to return data. Eventually it was scrapped, replaced with push. See nodejs/node-v0.x-archive#4878 for some reference.

[calvinmetcalf]

Chris that's why I was thinking of trying to make it a constructor option so that it would be easy to ignore Gil: interesting, I'd want it more to mirror _transform with a callback and push, just a callback would be pretty restrictive

[kanongil]

It seems my memory fails me. push was already there when it was removed. The callback was removed to simplify the interface & implementation .

[calvinmetcalf]

Was there some discussion somewhere?

On Tue, Feb 24, 2015, 5:48 PM Gil Pedersen [email protected] wrote:

It seems my memory fails me. push was already there when it was removed.
The callback was removed to simplify the interface & implementation .

—
Reply to this email directly or view it on GitHub
#113 (comment)
.

[mcollina]

Closing for no activity.