Thank you for this insightful post! I very much agree that the current streams interface is not designed for easy consumption, but rather as a way to simplify new stream implementations.
I did actually consider creating a Transform stream, as a way to solve my problem, but it was impossible without directly accessing the internal stream object. On 03/07/2013, at 09.32, Bruno Jouhier <bjouh...@gmail.com> wrote: > 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 nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com 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 nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
