diff --git a/website/node.html b/website/node.html
index 72a4643ff96..474139d8e48 100644
--- a/website/node.html
+++ b/website/node.html
@@ -164,6 +164,27 @@ make install
on
. All methods and members are camel cased. Constructors
always have a capital first letter.
+
puts(string, callback)
string
and a trailing new-line to stdout
.
+ The callback
argument is optional and mostly useless: it will
+ notify the user when the operation has completed. Everything in node is
+ asynchronous; puts()
is no exception. This might seem ridiculous
+ but, if for example, one is piping their output into an NFS'd file,
+ printf()
will block.
+ There is an internal queue for puts()
output, so you can be assured that
+ output will be displayed in the order it was called.
+
print(string, callback)
puts()
but without the trailing new-line.node.debug(string)
Timers allow one to schedule execution of a function for a later time. @@ -177,7 +198,38 @@ See Mozilla's documentation for more information. -
File system I/O has always been tricky because there are not any portable
+ways of doing non-blocking file I/O. To get around this, Node uses an internal
+thread pool to execute file system calls. Internal request queues exist for
+each node.File
instance so that multiple commands can be issued at
+once without worry that they will reach the file system out of order.
+Thus the following is safe:
+
file.open("/tmp/blah", "w+"); +file.write("hello "); +file.write("world"); +file.close();+Additionally there is a process-wide queue for all commands which operate on +the file system directory structure (like
rename
and
+unlink
.) It's important to understand that all of these request queues are
+distinct. If, for example, you do
+fileA.write("hello"); +fileB.write("world");+it could be that +first
fileB
gets written to and then fileA
gets written to.
+So if a certain operation order is needed involving multiple files, use the
+completion callbacks:
+fileA.write("hello", function () { + fileB.write("world"); +});+ +
node.File.rename()
node.tcp
HTTP message headers are represented by an array of 2-element arrays like this +
+[ ["Content-Length", "123"] +, ["Content-Type", "text/plain"] +, ["Connection", "keep-alive"] +, ["Accept", "*/*"] +] ++
Dictionary-like objects are popularly used to represent HTTP headers but they are
+an incorrect abstraction. It is rare, but possible, to have multiple header lines
+with the same field. Setting multiple cookies in a single response, for
+example, can only be done with multiple Cookie
lines.
+
node.http.Server
node.http.ServerRequest
This object is created internally by a HTTP server—not by the user.
-It is passed as the first argument to the This object is created internally by a HTTP server—not by the user.
+It is passed to the user as the first argument to the
callback.
request_handler
callback.
@@ -254,14 +319,6 @@ class="sh_javascript">request_handler
req.headers
-[ ["Content-Length", "123"] -, ["Content-Type", "text/plain"] -, ["Connection", "keep-alive"] -, ["Accept", "*/*"] -] -
req.httpVersion
"1.1"
,
@@ -295,6 +352,11 @@ req.onBody = function (chunk) {
node.http.ServerResponse
This object is created internally by a HTTP server—not by the user.
+It is passed to the user as the second argument to the request_handler
callback.
+
+
res.sendHeader(statusCode, headers)
An HTTP client is constructed with a server address as its argument, then the user issues one or more requests. Depending on the server connected to, the client might pipeline the requests or reestablish the connection after each -connection. (CURRENTLY: The client does not pipeline.) +connection. Currently the client does not pipeline requests.
Example of connecting to google.com