> On Aug 7, 11:30 pm, Isaac Schlueter <i...
> > On Sun, Aug 7, 2011 at 06:28, Bruno Jouhier <bjouh...
> > > Again, you speak about things without looking at them.
> > > The *non-fibers callback version* of this DOES EXIST.
> > > Streamline.js has nothing to do with fibers. It is a preprocessor that
> > > transformed file (https://github.com/Sage/streamlinejs/blob/master/
> > > lib/
> > > streams/server/streams.js), you will see that this is a PURE CALLBACK
> > > implementation of this API, which does not have any strings attached
> > > to it: no node C++ extension, not even a JS helper module -- it only
> > > 'requires' modules from node core!
> > So, your claim is that the streamline code is better than the callback
> > version generated by streamline? That's not terribly impressive.
> In this particular instance, 90% of the source is actually written in
> callback-style and is not transformed at all. This module is not at
> all a typical streamline module. It does not deal with business logic.
> It deals with a low level technical problem: transforming event-style
> code into callback-style. I'm just using streamline in one or two
> methods because this was handy. I could have as well written all of it
> in callback-style. Maybe I'll do it some day to make it a bit more
> > > I can provide hundreds of code fragments that demonstrate the
> > > difference in usability. I just need a bit of time to format them
> > > properly.
> > Not looking for fragments. Looking for the effect on a small,
> > finished, well-understood program. Otherwise, this is all just make
> > believe.
> > Is recursive directory removal too hard to do with fibers or
> > streamline or coroutines?
> Well, this is a technical problem (dealing with retries and all that
> stuff). Typically the kind of thing that I might still write in
> callback-style (or rather let you write for me!).
> I'd rather go with small typical samples of business logic. Because
> then I can explain what I mean by "easy to read and easy to
> maintain" (as you'll see, the maintenance issue takes a very different
> form than in the technical layers). As I said earlier, there is no
> "one size fits all" and I did not pretend that streamline or fibers
> were the right tools for what you are writing (I said the opposite).
> The best format to explain this is probably as a blog post and it is
> going to take me some time to do so (especially as my week-ends are
> currently very loaded with lots of down to earth duties). So please be
> a bit patient.
> Time to quit, if you don't mind.
> Job Board: http://jobs.nodejs.org/
> 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@example.com
> To unsubscribe from this group, send email to
> For more options, visit this group at