My take on streams2: The problem is not just an API issue, this is the consequence of a risky design choice.
Node streams are designed so that your code lives *inside* a stream which will be piped into other streams. This is very different from the usual model where most of your code lives *outside* of streams and where your code just reads and writes from streams. This is why the node streams2 API does not provide any convenient API to read from a stream. If you want to do this, you have to create a writable stream and pipe your input into it. Your code will live *inside* the writable stream. The reading will be done by implementing the "writable" interface. The idea of packaging code as streams and assembling systems by piping streams into each other is not necessarily a bad one (it is rather cool). The problem is that this is a high level abstraction which has been promoted as a low level API. The low level API should be a pair of simple read/write calls (no fancy events, no fancy class machinery, just async calls). The streams + pipe model can be easily scaffolded around this low level API. Then people who just want to read and write from streams can do it, and those who want to design their systems as streams and pipes can also do it. I also think that there was a misunderstanding about back pressure; namely that back pressure had to be *explicitly* handled through a pipe API. With a simple callback based design back pressure is "implicitly" handled by the event loop. The callback design is also more decoupled: the read side takes care of the little pause/resume dance; the write side takes care of the write/drain dance, and the coupling happens "naturally" through the event loop. No need for explicit pipe calls! Bruno On Wednesday, July 3, 2013 6:22:34 AM UTC+2, tjholowaychuk wrote: > > Yeah I agree with Eldar personally, it's not a great user-level API, and > the stream API we have in node right now is really error-prone to and > overly complex to work with, hiding them whenever possible is definitely > the way to go, there's nothing I've been happier avoiding in node so far! > > On Tuesday, 2 July 2013 09:46:29 UTC-7, Eldar wrote: >> >> I came to the value that the best thing to deal with node streams is not >> deal with them at all. >> Wrap them as soon as possible, do not pass them around, do not >> build abstractions on top of them. >> It is a super complected thing capable of what? You even can't do >> `send(file)`. Just can't. >> There are already tons of libs relaying on `req.pipe(res)`. But that's >> just a myth. It never was save. >> > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
