>However, the end result is a higher level abstraction of streams that should live in user land not core.
The end result is not a higher level abstraction just because you can convert simple-stream to 100% compatible core stream and vice versa. >I would argue this is an education problem, not a code problem That's a code which causes education/documentation problems. It also already established a bad practice of ignoring errors. I am not joking or exaggerating when saying: "Almost every module in npm has this flow...". See this<https://github.com/jprichardson/node-fs-extra/blob/master/lib/copy.js#L31> , that<https://github.com/substack/node-browserify/blob/master/index.js#L204> for example. There are many merits of using common stream API. Streams are important concept in core. So it's a sane idea to have a good core API for that. But let's just stop using streams2 in userland for now. вторник, 13 августа 2013 г., 14:42:39 UTC+4 пользователь nwhite написал: > > > > file.pipe(res) > file.on('error', res.destroy.bind(res)) > res.on('error', file.destroy.bind(res)) > > > What is wrong with this? I don't see an issue with streams/pipe. You could > argue that docs and tutorials need to be clearer about error handling. > > I would argue this is an education problem, not a code problem. Pipe is > not a high level API, it's a nice helper for some extremely low level > stuff. > > I like the explicitness in error handling. Besides it gives you options. > There are cases when you may not want to bail instantly or do some cleanup > before destroying. Tucking away error handling would create more issues. > > I can see merits to your argument in limited scenerios. However, the end > result is a higher level abstraction of streams that should live in user > land not core. > > вторник, 13 августа 2013 г., 12:58:09 UTC+4 пользователь Floby написал: >> >> ok. >> I didn't understand the part about " `.pipe()` doesn't cleanup any >> resources. >> Everything works fine until the streaming process completes successfully. >> " >> >> Is there an example where that becomes obvious? >> >> On Monday, 12 August 2013 18:05:02 UTC+2, Eldar wrote: >>> >>> If you want to create some function which accepts a stream and can affect >>> it's state you should be able to destroy the given stream on demand >>> e.g. when something went wrong and/or you are not interested in receiving >>> data anymore. >>> Unfortunately that's impossible with current node readable streams because >>> they: >>> >>> 1. Support multiple consumers >>> 2. Don't have common cleanup interface >>> >>> So you can't touch another's stream because someone else may use it >>> and if you could you don't know how. >>> >>> The absence of ability to pass streams as arguments is a huge flow. You can >>> build almost nothing >>> without that. Now someone may wonder: but there are so many useful modules >>> about streams in npm!? >>> Right. They all rely on `.pipe()`. For some reason all kind of blog posts, >>> tutorials and even node's >>> own documentation teach that for passing readable you can do >>> `readable.pipe(writable)`. >>> E.g. http file server could be: >>> >>> ```javascript >>> var http = require('http') >>> var fs = require('fs') >>> http.createServer(function(req, res) { >>> res.writeHead(200, {'Content-Type': 'text/plain'}) >>> fs.createReadStream(req.url.slice(1)).pipe(res) >>> }).listen(3000) >>> ``` >>> >>> That's a lie. Exactly for the reasons above `.pipe()` doesn't cleanup any >>> resources. >>> Everything works fine until the streaming process completes successfully. >>> But if something fails you get horrible leaks and hangs. >>> Almost every module doing stream processing have this flow. Obvious or not. >>> >>> That all is sad. We need another, simpler API. Although I believe >>> incompatible changes should be made >>> to node core that is not what I am calling about (at least not at the first >>> place). >>> But we definitely should stop to expose node streams in userland modules, >>> stop to extend "stream base classes", just stop to use it in userland. >>> >>> Now the constructive part. Tim Caswell proposed recently simple-stream >>> <https://github.com/creationix/js-git/blob/master/specs/simple-stream.md> >>> and build many things on top of it. >>> >>> Let's just peek this API as a standard and start using it. >>> Here is readable-to-simple-stream >>> <https://github.com/eldargab/stream-simple> converter which can be used for >>> dealing with node core. >>> >>> It also contains slightly more detailed version of original spec which >>> could be discussed. >>> >>> That's it. >>> >>> -- > -- > 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 nod...@googlegroups.com <javascript:> > To unsubscribe from this group, send email to > nodejs+un...@googlegroups.com <javascript:> > 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+un...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- -- 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.
