Request Object loosing events?

[Stephan Bruny]

Hello,

the following code puzzles me a lot:

http.createServer(function (request, response) {
request.on('data', function(data) {console.log('WORKS: ' +
data.toString())});
var route = routing.resolveUrl(request.url,
config.routes);

path.exists(config.directories.application + route.action,
function(exists) {
request.on('data', function(data) {console.log('DOES
NOT WORK ' + data.toString())});
if (exists === true) {
// call an action
} else {
// show 404
});
}
})

}).listen(port, adress);

As soon, as I run into the callback at path.exists, I get no callback
call from request on any(!) event.
But the request object is still there (well, according to the debugger
at least)
Is it not possible to nest events that much?

[mscdex]

On Apr 23, 9:12 am, Stephan Bruny <the.deathg...@googlemail.com>
wrote:

> As soon, as I run into the callback at path.exists, I get no callback
> call from request on any(!) event.
> But the request object is still there (well, according to the debugger
> at least)
> Is it not possible to nest events that much?

It is possible. However my guess is that by the time path.exists()
executes its callback, there is no more data being emitted on the
request's 'data' event.

If that is the case, what you could do is buffer the incoming data
until the path.exists() callback is executed. At that point, you could
then remove the original 'data' listener and then prepend the data
you've already buffered with any new data that comes in on your new
innermost 'data' listener.

[Mikeal Rogers]

this is an intentional part of the design, i've covered this a lot when speaking about "intro to node" stuff.

basically the rule is, you can't attache listeners to an event emitter which is the subject of an event itself inside of callback. you should actually try to design around this by stating the tree and using file watchers to update an in-memory representation of the file tree if possible.

you can also use my buffered stream, which we may want to put in core.

https://github.com/mikeal/morestreams/blob/master/main.js#L6

basically, you create a buffered stream, pipe to it at the start of the callback, then pipe out of it when the callback returns.

http.createServer(function (request, response) {
  var b = new morestreams.BufferedStream();
  request.pipe(b);

  var route = routing.resolveUrl(request.url,
config.routes);
  path.exists(config.directories.application + route.action,
function(exists) {

    if (exists) b.pipe(new MyStream());


        }).listen(port, adress);

[Bruno Jouhier]

We hit the same issue and I just published a blog post on the subject
(with a link to this thread):
http://bjouhier.wordpress.com/2011/04/25/asynchronous-episode-3-adventures-in-event-land/

Bruno

On Apr 23, 3:12 pm, Stephan Bruny <the.deathg...@googlemail.com>
wrote:

[Mikeal Rogers]

buffering all the data is not the proper way to solve this if the intention is to send the data to another file handler.

[Bruno Jouhier]

@Mikeal,

Don't know if this is in reply to my post but the solution that I am
proposing uses pause and resume under the hood. The default setting is
very conservative and pauses the stream as soon as one chunk has been
buffered. You can control it by setting low and high water marks in
the options.

Bruno