New server-side js project: Node
Ryan Dahl
event-based interface to I/O:
* TCP server and client
* Standard setTimeout() setInterval() timers
* Asynchronous file I/O
* HTTP server and client
Node's main focus is on performance and efficiency. It is built on top of
* V8 javascript
* libev, event loop abstraction
* libeio, file I/O thread pool
Node has the goal of supporting most POSIX operating systems
(including Windows through MinGW) but at the moment it is only being
tested on Linux, Macintosh, and FreeBSD. Node has no external
dependencies (V8 and other libraries are included in its source tree.)
Node strives to provide complete and good documentation. This goal is
not yet met but there is enough material to allow one to get started.
Node is released under an MIT license.
Relase v0.0.2
http://s3.amazonaws.com/four.livejournal/20090531/node-0.0.2.tar.gz
Website
http://tinyclouds.org/node/
API documentation
http://tinyclouds.org/node/api.html
Git Repository
http://github.com/ry/node
Feedback welcome
Donny Viszneki
> http://s3.amazonaws.com/four.livejournal/20090531/node-0.0.2.tar.gz
> http://tinyclouds.org/node/
> http://tinyclouds.org/node/api.html
Hmmm....
Plans to run Node on Amazon EC2???
Roberto Saccon
just yesterday I spotted a implementation-wise similar project (but
with focus on http-push):
http://www.ape-project.org/
Is node out-of-the-box suitable for an iPhone push notification
server ? Anybody spent thoughts on that ?
regards
Roberto
Donny Viszneki
> just yesterday I spotted a implementation-wise similar project (but
> with focus on http-push):
> http://www.ape-project.org/
Does APE run Javascript on the server side?
Roberto Saccon
tried it out, and I don't like their license (GPL)
On May 31, 1:47 pm, Donny Viszneki <donny.viszn...@gmail.com> wrote:
Wes Garland
Cool !
just yesterday I spotted a implementation-wise similar project (but
with focus on http-push):
http://www.ape-project.org/
Is node out-of-the-box suitable for an iPhone push notification
server ? Anybody spent thoughts on that ?
I haven't started iPhone dev yet, but it's on my very short list. If you wind up building/working with something that can do spidermonkey + iphone push, I'd be particularly interested.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
mob
license closely. Apple specifically prohibit interpreters on the
iPhone.
mob
http://www.ejscript.org
On May 31, 11:26 am, Wes Garland <w...@page.ca> wrote:
Ryan Dahl
> server ? Anybody spent thoughts on that ?
Node definitely is designed with the idea of building long-poll "push"
style web applications. It's actually one of the motivations for the
project. (Having many hanging connections almost demands an
event-based design.)
I don't know anything about iPhone, but v8 does work on ARM
architectures. As long as the iPhone OS supports the common POSIX
system calls, Node should as well.
Kris Kowal
I gave a shot at building a Narwhal platform on Node today. The
bootstrapping process unfortunately depends on having a synchronous
file read *option* (among other synchronous versions) at least so that
modules can be loaded synchronously. I'm considering experimenting
with modules in a parallel universe where any function call that may
be async may return a Promise, including "require", and in that world
it would be possible to use Node for a ServerJS platform, but not in
the present one. It's my hope that with those experiments, I might
discover a way to sacrifice some elegance of the underlying Promise
API in favor of a smoother developer experience, or contrive some way
to translate async to sync require reliably, or at least learn exactly
why that isn't possible.
Ryan, you might also want to look into promises. It's been mentioned
that callbacks are a dead-end here, and in earnestness, it's true. I
discovered when I made an async module loader several years ago (old
version of Chiron) that for transitive dependencies it was necessary
for "require" to not only accept a callback, but to pass to that
callback a hook that would notify the observer that the callback,
although it had already returned, was actually still waiting for other
modules to load before its own exported API would function properly.
This is the essential function of promises, except they are more
generally useful, providing a basis for any transitive asynchronous
calls.
I'm going to post soon on how you can play with promises in Narwhal to
get a feel for what we've been talking about.
Kris Kowal
Ryan Dahl
Great!
> The bootstrapping process unfortunately depends on having a synchronous
> file read *option* (among other synchronous versions) at least so that
> modules can be loaded synchronously.
This could be added if it meant supporting Narwhal/serverjs API.
> Ryan, you might also want to look into promises. It's been mentioned
> that callbacks are a dead-end here, and in earnestness, it's true.
My problem with promises is that it seems quite syntax heavy. I'd
prefer to have a simple callback API and allow something like promises
to be built on top of that.
.(Also I'd prefer a more DOM-like nomenclature of emitting events,
bubbling, etc. instead promises. But as this is likely, in Node, to be
built on top of the C++/V8 hooks I provide to the event loop and
internal thread pool, I'm more or less agnostic.)
> I discovered when I made an async module loader several years ago (old
> version of Chiron) that for transitive dependencies it was necessary
> for "require" to not only accept a callback, but to pass to that
> callback a hook that would notify the observer that the callback,
> although it had already returned, was actually still waiting for other
> modules to load before its own exported API would function properly.
> This is the essential function of promises, except they are more
> generally useful, providing a basis for any transitive asynchronous
> calls.
Node does transitive dependencies.
Donny Viszneki
> On Sun, May 31, 2009 at 11:49 AM, Ryan Dahl <coldre...@gmail.com> wrote:
> I gave a shot at building a Narwhal platform on Node today. The
> bootstrapping process unfortunately depends on having a synchronous
> file read *option* (among other synchronous versions) at least so that
> modules can be loaded synchronously. I'm considering experimenting
> with modules in a parallel universe where any function call that may
> be async may return a Promise, including "require", and in that world
> it would be possible to use Node for a ServerJS platform, but not in
> the present one.
You could return a promise or just block until the async operation
completes. Either way seems rather simple, so what's the problem?
Brian Hammond
On May 31, 2:49 pm, Ryan Dahl <coldredle...@gmail.com> wrote:
> > Is node out-of-the-box suitable for an iPhone push notification
> > server ? Anybody spent thoughts on that ?
>
> Node definitely is designed with the idea of building long-poll "push"
> style web applications. It's actually one of the motivations for the
> project. (Having many hanging connections almost demands an
> event-based design.)
suppose I can proxy pass SSL connections in nginx to Node.
> I don't know anything about iPhone, but v8 does work on ARM
> architectures. As long as the iPhone OS supports the common POSIX
> system calls, Node should as well.
notifications, which doesn't run on an iPhone.
Ryan Dahl
<or.else.it.g...@gmail.com>
>> Node definitely is designed with the idea of building long-poll "push"
>> style web applications. It's actually one of the motivations for the
>> project. (Having many hanging connections almost demands an
>> event-based design.)
>
> Definitely. I wonder what your thoughts are regarding SSL support. I
> suppose I can proxy pass SSL connections in nginx to Node.
TLS support is approximately 40% complete. It's supported in my C
language socket layer through cooperation with GnuTLS but there is no
javascript interface for it yet. It's on my todo list, but there are
several other items ahead of it, so it might be a while.
Brian Hammond
> TLS support is approximately 40% complete. It's supported in my C
> language socket layer through cooperation with GnuTLS but there is no
> javascript interface for it yet. It's on my todo list, but there are
> several other items ahead of it, so it might be a while.
a simple boolean indicating "this connection was over TLS" in your JS
API?
Donny Viszneki
Just an idle suggestion: a more forward-looking approach would be a
"transport" or "protocol" member that would let you find that out.
HTTP over TLS/SSL may have a richer non-boolean future since there is
some small demand to *sign* a transmission without *encrypting* it.
It was, however, a *long* time ago when last I heard about this. Maybe
it's even available somewhere and I don't know about it.
Kevin Dangoor
> My problem with promises is that it seems quite syntax heavy. I'd
> prefer to have a simple callback API and allow something like promises
> to be built on top of that.
What is syntax heavy about promises?
return readfile("foo").addCallbacks(function(data) {
// do stuff with the data
});
You just have to put that call outside of the async function call and
then you get all of the goodness of the promise style.
Kevin
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com