Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nice! I love Node for these kind of asynchronous handling of data, it fits perfectly. Keep in mind you can go down the stream route. Instead of:

    ps.stdout.on 'data', (data) -> ws.send data.toString()
    ws.on 'message', (data) -> ps.stdin.write data.toString()
Just do:

    ps.stdout.pipe ws
    ws.pipe ps.stdin
I started using Node before Streams and I often forget piping too!

I still have a question for Node.js experts... would the 'close' events had to be handled then? Streams handle and propagate the 'end' event just fine, but should the underlying resource be closed? I guess killing `ps` is mandatory since ending `stdout` won't kill the process (or will it?), but is closing `ws` still mandatory too?



If the socket is terminated mid-command (thus emitting 'close'), one would want the process to be killed. Also, the socket doesn't know that no more transmission is required just because one particular stream is over. That is why close is called manually on the socket after the stream emits a 'close'.

This all provided you use a streaming web socket module like https://github.com/maxogden/websocket-stream


I thought about using pipe but the WebSocket library doesn't implement the Stream API, does it?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: