> > Can't you just run the code on the client side and hook it into the > server with dnode or something like that? (Or regular AJAX if you're > worried about DoS attacks - as soon as you run something like socket.io, > you're pretty much defenseless against mildly sophisticated DoS attacks. > A few months ago, you could let nodes RAM overflow remotely with a > single shell command if the remote side was running socket.io (endless > POST), and now.js was even more vulnerable - a single tiny message, and > node completely blocked the event loop. At the moment, it probably takes > a small script to kill a socket.io instance, but it's not hard.) >
Unfortunately not. There really isn't a need for AJAX or sockets. The code responds to events during a GET/POST. The lifecycle of the code is very short. Any validation that happens on the client side has to be also done on the server side. What we're doing is very PHP-like. Probably the biggest factor of me looking at V8 is because JavaScript is so widely used, no matter what server side technology you use (PHP, ASP, Java, etc..). The learning curve for our users would not be nearly as high. The appeal of Node for me is having a single application instance that's constantly running that can respond to events. Being able to monitor these events as they happen is appealing. Perhaps what I need to do is look at v8cgi, PHP+V8JS, or stick with PHP+AST parser and use Node as a way to monitor/respond-to events. -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
