Fix up description on web page

website/index.html

@@ -14,7 +14,7 @@
 
 <h1><a href="http://tinyclouds.org/node">Node</a></h1>
 
-<p id="introduction">Purely evented I/O for <a
+<p id="introduction">Purely event-based I/O for <a
   href="http://code.google.com/p/v8/">V8 javascript</a>. 
 
 <p>An example of a web server written with Node which responds with
@@ -39,18 +39,22 @@ Server running at http://127.0.0.1:8000/
 
 <p> See the <a href="api.html">API documentation</a> for more examples.
 
-<p> Node's goal is to provide easy, scalable concurrency. In the above example,
+<p> Node's goal is to provide an easy way to build scalable network
-the 2 second delay does not prevent the server from handling new requests.
+programs.
-
+In the above example, the 2 second delay does not prevent the server from
-Node tells the operating system (through <code>epoll</code> or
+handling new requests.
-<code>kqueue</code> or <code class="sh_none">/dev/poll</code> or <code>select</code>) that it
+Node tells the operating system (through 
-should be notified when the 2 seconds are up or if a new connection is
+<code>epoll</code>,
-made&mdash;then it goes to sleep. If someone new connects, then it executes
+<code>kqueue</code>,
-the callback, if the timeout expires, it executes the inner callback.
+<code class="sh_none">/dev/poll</code>, 
-Each connection is only a small heap allocation.
+or <code>select</code>) 
-
+that it should be notified when the 2 seconds are up or if a new connection
-<p>This is in contrast to most scripting languages  where OS threads are employed for
+is made&mdash;then it goes to sleep. If someone new connects, then it
-concurrency. But thread-based networking 
+executes the callback, if the timeout expires, it executes the inner
+callback. Each connection is only a small heap allocation.
+
+<p>This is in contrast to today's more common model
+where OS threads are employed for concurrency. But thread-based networking 
 <a href="http://www.sics.se/~joe/apachevsyaws.html">is</a>
 <a href="http://www.kegel.com/c10k.html">relatively</a>
 <a href="http://bulk.fefe.de/scalable-networking.pdf">inefficient</a>
@@ -60,55 +64,46 @@ very
 difficult 
 to 
 use. 
+
+<p>
 Node will show much better memory efficency under high-loads 
 <!-- TODO benchmark -->
-than other systems 
+than systems which allocate 2mb thread stacks for each connection.
-which allocate 2mb thread stacks for each connection.
+
+<p>Users of Node are free from worries of dead-locking the
+process&mdash;there are no locks.  In fact, there arn't even blocking
+functions. Because nothing blocks, Node can be given to less-than-export
+programmers to build servers.
 
-Node is similar to systems like
+<p>Node is similar to systems like
 Ruby's <a href="http://rubyeventmachine.com/">Event Machine</a>
 or
 Python's <a href="http://twistedmatrix.com/">Twisted</a>.
-But Node also provides full access to the file system in a non-blocking way.
+But Node takes the paradigm. 
-(This is done by using an internal thread pool to handle file system calls.)
+In other systems, there is always a blocking call to start the event-loop.
-Because Javascript does not have I/O libraries and because <i>nothing</i> in
+Typically one sets up behavior through callbacks and at the end starts the
-Node blocks, a Node programmer is going to find it difficult to write slow
+server through a  call like <code>EventMachine::run()</code>. In Node, 
-servers&mdash;even if they don't understand how the concurrency system
+there is no such thing. By default Node enters the event loop after
-works.
+executing the input script. Node exits the event loop when there are no more
-
+callbacks to perform. 
-<p>Notice in the above example the <code>puts()</code> call is made
+
-immediately. 
+<p>Node's HTTP server has grown out of my difficulties developing
-
+and working with web servers.  For example, streaming data through most web
-<p>Node's HTTP API has grown out of my difficulties while developing for
+frameworks is difficult or impossible.  Or like the oft-made false
-Merb and Ebb. Because of limiting low-level design choices, streaming data
+assumption that all message headers have unique fields.  Node attempts to
-through Rack-based frameworks is difficult or impossible.  Streaming is
+correct these problems by providing a low-level but complete HTTP API.
-important for large requests or responses (uploads or downloads), so that
+Coupled with Node's purely evented infrastructure, it will make a solid foundation for
-the data is not buffered in memory.  Other small problems, the incorrect
+future frameworks.
-assumption that all message headers have unique fields are dealt with. The
+
-result is a fast, scalable, and complete low-level HTTP API which can be
+<p> <i>But what about multiple-processor concurrency? Threads are necessary
-built upon.
+to scale programs to multi-core computers.</i> The name <i>Node</i> should
-
+give some hint at how it is envisioned being used.  Processes are necessary
-<p> Evented program is different. It requires the program to change how they
+to scale to multi-core computers, not memory-sharing threads.  The
-view the problem. But it provides many benefits and it more closely matches
-what the machine is actually doing. In someways threaded programming is like
-fitting a square block into a round hole, and all of the deadlocks and
-memory inefficiencies that come from that are a result of the struggle.
-Javascript, thankfully, has no concept of threads
-<a
-href="http://weblogs.mozillazine.org/roadmap/archives/2007/02/threads_suck.html"
->and never will</a>. It has a very lucid closures and anonymous functions,
-which make evented programming tolerable.
-
-<p> "But what about multiple-processor concurrency?", you ask. "Threads are
-necessary to scale programs to multi-core computers." The name <i>Node</i>
-should give some hint at how it is envisioned being used.  Processes are
-necessary to scale to multi-core computers, not memory-sharing threads.  The
 fundamentals of scalable systems are fast networking and non-blocking
 design&mdash;the rest is message passing.  In the future, I'd like Node to
-be able to spawn new processes, have a library for passing JSON messages,
+to be able to spawn new processes (probably using the <a
-and be able accept connections from multiple processes (a pre-fork server);
+href="http://www.whatwg.org/specs/web-workers/current-work/">Web Workers
-but these are things that fit into the current design and do not require
+API</a>), but this is something that fits well into the current design.
-threads.
 
 <p> Node is released under an MIT license.</p>
 
@@ -129,7 +124,8 @@ href="http://s3.amazonaws.com/four.livejournal/20090527/node-0.0.1.tar.gz">node-
 <p>Node eventually wants to support all POSIX operating systems (including
 Windows with mingw) but at the moment it is only being tested on Linux,
 Macintosh, and FreeBSD.  The build system requires Python.  V8, on which
-Node is built, supports only IA-32 and ARM processors. 
+Node is built, supports only IA-32 and ARM processors. V8 is included in the
+Node distribution. There are no dependencies.
 
 <pre class="sh_none">
 ./configure