Purely event-based I/O for V8 Javascript(97.107.132.72)
97.107.132.72
Purely event-based I/O for V8 Javascript
http://97.107.132.72/node/
5 comments
The Narwhal project (http://narwhaljs.org/) attempts to make JavaScript generally more useful and pleasant outside the browser, adding a module system, standard library, package manager, etc.
It's designed to be interpreter agnostic, by implementing as much as possible in JavaScript, only dropping down to native modules where necessary (file io, etc). Currently Rhino is the best supported platform but people are working on V8 and Mozilla support as well.
It's still a work in progress but it's at the point where you can start playing with it. All of the Cappuccino build tools use it now, btw.
Then there's JSGI and Jack (http://jackjs.org/), which is how you interface with webservers. JSGI is a standard interface for JavaScript web applications and middleware, and Jack is an implementation of several web server adapters, middleware, and utilities, essentially a port of Ruby's Rack.
It's designed to be interpreter agnostic, by implementing as much as possible in JavaScript, only dropping down to native modules where necessary (file io, etc). Currently Rhino is the best supported platform but people are working on V8 and Mozilla support as well.
It's still a work in progress but it's at the point where you can start playing with it. All of the Cappuccino build tools use it now, btw.
Then there's JSGI and Jack (http://jackjs.org/), which is how you interface with webservers. JSGI is a standard interface for JavaScript web applications and middleware, and Jack is an implementation of several web server adapters, middleware, and utilities, essentially a port of Ruby's Rack.
I played around with node last night a bit more. Here are one noob's observations:
For most things it feels pretty fast. A simple timer output showed less than 1, 1, 2 or 3 milliseconds for most operations including File I/O.
Importing files via node's 'import' and 'require' functions is, for lack of a better adjective, Erlang-ish. You must declare in the file you are importing which functions you would like to expose by making them members of a special object called 'exports'. For example if you have a factorial function in a file called factorial.js you must declare it as 'exports.factorial = function() { ... }'. This seems 1) strange, 2) not very Javascripty and 3) like it can severely limit the reuse of server-side js libs with other server-side and non-server-side js implementations. This was the biggest let down for me, since my dream is to be able to write libs that work on both the client and the server.
There was a weird bug I found when writing to a file. If I created a loop like so:
var times = []; for (var i=0,j=1000; i<j; i++) { var t1 = Date.now(); var file = new node.fs.File(); file.open('test.log', 'a+'); file.write(i + ' ' + new Date() + ' Hello World!\n'); file.close(); times.push(Date.now() - t1); }
'file' would contain only 250 new lines of text, while the array times would show it's length to be 1000. I'm assuming this is some kind of bug, as the number of new lines added to the file seems fixed at 250. Setting the loop to 249 produced a times array with 249 items and a file with 249 new lines. Setting the loop to 251 produced a times array with 251 items and a file with 250 new lines. My C++ is very poor, but my guess is that each event has a queue which is hard coded at 250 and my loop over flowed the queue. This could also be a potentially huge issue with writing libraries around node.
It would be nice to see those two issues resolved or explained in better detail, particularly the import / export functionality.
For most things it feels pretty fast. A simple timer output showed less than 1, 1, 2 or 3 milliseconds for most operations including File I/O.
Importing files via node's 'import' and 'require' functions is, for lack of a better adjective, Erlang-ish. You must declare in the file you are importing which functions you would like to expose by making them members of a special object called 'exports'. For example if you have a factorial function in a file called factorial.js you must declare it as 'exports.factorial = function() { ... }'. This seems 1) strange, 2) not very Javascripty and 3) like it can severely limit the reuse of server-side js libs with other server-side and non-server-side js implementations. This was the biggest let down for me, since my dream is to be able to write libs that work on both the client and the server.
There was a weird bug I found when writing to a file. If I created a loop like so:
var times = []; for (var i=0,j=1000; i<j; i++) { var t1 = Date.now(); var file = new node.fs.File(); file.open('test.log', 'a+'); file.write(i + ' ' + new Date() + ' Hello World!\n'); file.close(); times.push(Date.now() - t1); }
'file' would contain only 250 new lines of text, while the array times would show it's length to be 1000. I'm assuming this is some kind of bug, as the number of new lines added to the file seems fixed at 250. Setting the loop to 249 produced a times array with 249 items and a file with 249 new lines. Setting the loop to 251 produced a times array with 251 items and a file with 250 new lines. My C++ is very poor, but my guess is that each event has a queue which is hard coded at 250 and my loop over flowed the queue. This could also be a potentially huge issue with writing libraries around node.
It would be nice to see those two issues resolved or explained in better detail, particularly the import / export functionality.
I meant exactly that. What depresses me is the lack of cooperation among "v8 std libs" and multitude of half-baked projects.
Isn't the IP address following the post name reversed from what it should be?
Actual URL, http://tinyclouds.org/node/
Marketingwise, well done. Otherwise, there are lots of "v8 standard library" projects out there: k7, v8-juice and many more.
Are Node people going to reimplement event-driven MySQL client from scratch or what?
Diving into the code...
> Are Node people going to reimplement event-driven MySQL client from scratch or what?
No. MySQL does not provide an API that is usable with an event-loop, so it will need to be run in a separate internal thread. It will notify the main thread when it is complete. With Postgres the situation is better, they have a very nice API that can be integrated into an event loop, so the extra overhead won't be necessary.
No. MySQL does not provide an API that is usable with an event-loop, so it will need to be run in a separate internal thread. It will notify the main thread when it is complete. With Postgres the situation is better, they have a very nice API that can be integrated into an event loop, so the extra overhead won't be necessary.
I'm not familiar with how other libraries might be implemented, like mysql, sqlite, etc so I guess I'm wondering if this implementation will eventually support external libraries. Also wondering how node compares to, say, narwhal:
http://github.com/tlrobinson/narwhal/commits/master
which seems to be more of a std lib than a full runtime. Also, can narwhal be imported by node?
All in all, really exciting. I've been wanting js on the server forever.