On Sat, Apr 28, 2012 at 10:25 AM, Oliver Leics <oliver.le...@gmail.com>wrote:
> On Sat, Apr 28, 2012 at 4:07 PM, Tim Caswell <t...@creationix.com> wrote: > > Stream: A stream is closer to a callback than an event emitter even > though > > [..] > > Streams are > > meant to be used to pipe data between processes and sockets. where data > > can't be shared via references and you don't want to buffer everything at > > every point. > > Is the following statement always true? > > "A prime number generator that implements the stream-interface but > never pipes its data to another process or socket should better not > implement the stream-interface." > > (I don't want to troll or something like that, I really want to know > your opinions about that) > In that case I would say that a stream interface is overkill. But like most things, it depends on what you're interfacing with and your personal preference for abstraction. If the code you're interfacing with expects a stream interface, even though it's in-process, there is something to be said for a consistent interface. A prime number generator is a "generator". That means you pull data from it when you want the data. There is no outside force creating the numbers pushing them to you. The generator Bruno wrote would be a good abstraction for an on-demand prime generator. (Or use harmony generators if you prefer it as a language feature) If the generator uses threads and is generating primes as fast as possible in a worker, then maybe an event emitter or stream would make sense. In that case there is a real event source. Some other code running in another thread notifies you when it has data. If the data is small enough to buffer and you don't need the primes till they are all generated, then use a single callback. It's less times to synchronize the two threads. If there is a ton of data and it's infeasible to buffer or wait till it's all done, then emit data as it happens (Event Emitter). If you want to pipe the data to some other process or write to disk or something that had hard bandwidth constraints, then use a full stream and implement a way to pause the number generator when the target is busy. That way you don't end up generating numbers faster than you can write them and blow up in memory. -- 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
