More doc tweaks

doc/guide/en/request_middleware.md

@@ -1,6 +1,6 @@
 # Request Middleware
 
-One of the most powerful and exiting features introduced in SocketStream 0.3 is Request Middleware. This has the power to inspect, transform, redirect or drop incoming requests over the websocket, HTTP API, or console.
+Request Middleware allows you to inspect, transform, redirect or drop incoming requests over the websocket, HTTP API, or REPL (using ss-console).
 
 If you've used Connect HTTP middleware before the concept and API will be instantly familiar. Essentially incoming requests can be processed through a chain of middleware BEFORE they arrive at their final destination - typically the RPC command you are requesting.
 
@@ -66,7 +66,7 @@ Simply pass the module/function directly. E.g:
 
 Creating custom middleware in your application is easy.
 
-Let's start by creating a function which multiplies incoming numbers (the first param).
+Let's start by creating an RPC action which multiplies incoming numbers (the first param).
 
 ```javascript
 // server/rpc/app.js

doc/guide/en/rpc_responder.md

@@ -32,7 +32,7 @@ exports.actions = function(req, res, ss){
 
 ### Sending Arguments
 
-The RPC Responder can take and pass unlimited arguments intuitively. For example let's write another action on the server:
+The RPC Responder can take and return unlimited arguments intuitively. For example let's write another action on the server:
 
 ``` javascript
 // server/rpc/products.js
@@ -62,7 +62,16 @@ ss.rpc('products.topSelling', '2012-01-01', '2012-01-31', productType, function(
   console.log('The top selling products in ' + productType + ' were:', products);
   console.log('And the best salesperson was:', bestSalesperson);
 })
+```
+
+The ability to pass multiple arguments also means you can choose to follow the 'error first' idiom typically used in Node:
 
+``` javascript
+// client/code/main/products.js
+ss.rpc('products.add', 123, function(err, data){
+  if (err) return alert("Error adding product!");
+  $('#products').append( ss.tmpl['product.details'].render(data) );
+});
 ```
 
 You may pass as many arguments as you want - just remember the last argument should always be the callback if you're expecting a response from the server.

doc/guide/en/server_side_testing.md

@@ -86,7 +86,7 @@ A new Session (with a unique ID) is automatically created for you the first time
 
 ### What can I test?
 
-Right now you can only test `ss.rpc()` commands. Once we finalize the API, you'll soon be able to test all third-party Request Responders (e.g. models) in a similar way.
+Right now you can only test `ss.rpc()` commands. A major goal of SocketStream 0.4 is to allow any Request Responders to be tested in a similar way.
 
 We are also considering implementing a mock Publish Transport, to allow you to test `ss.publish()` commands.
 

doc/guide/en/sessions.md

@@ -84,5 +84,5 @@ Any Redis configuration can be passed to the second argument (e.g `{port: 1234}`
 
 By default sessions will expire within 30 days, unless the session is terminated beforehand (e.g. the user closes the browser). To set a different expiry time put the following in your `app.js` file:
 
-    ss.session.options.maxAge = 8640000;  // one day in miliseconds
+    ss.session.options.maxAge = 8640000;  // one day in milliseconds
 

doc/guide/en/template_engine_wrappers.md

@@ -1,8 +1,10 @@
 # Template Engine Wrappers
 
-Writing your own template engine wrapper is easy. For this quick tutorial we'll be looking at a [ss-hogan](https://github.com/socketstream/ss-hogan), a wrapper for Twitter's [Hogan library](http://twitter.github.com/hogan.js/).
+SocketStream supports a wide variety of client-side template engines through the use of third party modules.
 
-You can see the file structure for a template engine wrapper in the [ss-hogan repository]([ss-hogan](https://github.com/socketstream/ss-hogan)). Let's look at the key file, `engine.js`:
+If you can't find a module for your preferred templating language, it's easy to create your own. This page guides you through the process, using the [ss-hogan](https://github.com/socketstream/ss-hogan) module (a wrapper for Twitter's [Hogan library](http://twitter.github.com/hogan.js/)), as a reference.
+
+Let's look at the key file in this module, `engine.js`:
 
 ```javascript
 /* engine.js */

doc/guide/en/using_emberjs.md

@@ -1,4 +1,7 @@
-# Use Ember MVC JS lib with SocketStream
+# Use Ember JS
+
+**Note: This doc file has been kindly contributed and is in need of a little editing. More info on using SocketStream with Ember can be found on our Google Group. Pull requests to improve this page would be appreciated.**
+
 
 Socketstream already support Ember MVC in the core and it is really easy to integrate your ember MVC end point into SocketStream framework.
 Following are steps to create an end-point with Ember view in SocketStream.

doc/guide/en/writing_request_responders.md

@@ -1,6 +1,6 @@
 # Writing your own Request Responder
 
-Note: This documentation is aimed at developers who are comfortable creating Node.js modules and wish to extend the core functionally of SocketStream. Writing Request Responders is going to become a lot easier in SocketStream 0.4.
+Note: This documentation is aimed at developers who are comfortable creating Node.js modules and wish to extend the core functionally of SocketStream. Writing Request Responders is going to become **a lot** easier in SocketStream 0.4.
 
 
 ### Introduction
@@ -101,13 +101,9 @@ We recommend you use the `apitree` NPM module for namespacing (as we do with the
 
 ### API Status
 
-The 'websocket' interface should now be stable. We're currently working on finalizing additional interfaces to allow your responder to be called over the REPL (using `ss-console`), as part of a server-side test suite, or even over HTTP requests.
-
-Additional interfaces will be documented shortly once they are stable - however you are not obliged to add them to your responder.
-
-We welcome feedback from developers and will use this to improve the API design in future releases. We will do our best to ensure any changes do not break the existing API, but getting this right for the long-term is of primary importance.
+The Request Responder API in 0.3 is now stable. SocketStream 0.4 will build upon the ideas in 0.3, allowing you to define additional 'interfaces' so your responder can be invoked over the REPL (using `ss-console`), as part of a server-side test suite, or even over HTTP requests.
 
 
 ### Support available!
 
-Please do not hesitate to get in touch if you need help at any stage of the process. Please log a Github issue or find us on IRC.
+Please do not hesitate to get in touch if you need help at any stage of the process. Please log a Github issue or find us on IRC (#socketstream channel on Freenode).