apply/make Travis's json-format branch prototype to work with latest restructured master; added StatusCode to JSONOutput server-function contract

docs/function-format.md

@@ -2,7 +2,7 @@
 
 This document will describe the details of how a function works, inputs/outputs, etc.
 
-## Formats
+## Input Formats
 
 ### STDIN and Environment Variables
 
@@ -18,9 +18,11 @@ The goals of the input format are the following:
 
 The format is still up for discussion and in order to move forward and remain flexible, it's likely we will just allow different input formats and the function creator can decide what they want, on a per function basis. Default being the simplest format to use.
 
-#### Default I/O Format
+TODO: Put common env vars here, that show up in all formats.
 
-The default I/O format is simply the request body itself plus some environment variables. For instance, if someone were to post a JSON body, the unmodified body would be sent in via STDIN. The result comes via STDOUT. When call is done, pipes are closed and the container running the function is terminated.
+#### Default Input Format
+
+The default format is simply the request body itself plus some environment variables. For instance, if someone were to post a JSON body, the unmodified body would be sent in via STDIN. The result comes via STDOUT. When task is done, pipes are closed and the container running the function is terminated.
 
 Pros:
 
@@ -30,14 +32,15 @@ Cons:
 
 * Not streamable
 
-#### HTTP I/O Format
+#### HTTP Input Format
 
 `--format http`
 
 HTTP format could be a good option as it is in very common use obviously, most languages have some semi-easy way to parse it, and it's streamable. The response will look like a HTTP response. The communication is still done via stdin/stdout, but these pipes are never closed unless the container is explicitly terminated. The basic format is:
 
 Request:
-```
+
+```text
 GET / HTTP/1.1
 Content-Length: 5
 
@@ -45,7 +48,8 @@ world
 ```
 
 Response:
-```
+
+```text
 HTTP/1.1 200 OK
 Content-Length: 11
 
@@ -66,34 +70,47 @@ Cons:
 * Requires a parsing library or fair amount of code to parse headers properly
 * Double parsing - headers + body (if body is to be parsed, such as json)
 
-#### JSON I/O Format (not implemented)
+#### JSON Input Format
 
 `--format json`
 
-The idea here is to keep the HTTP base structure, but make it a bit easier to parse by making the `request line` and `headers` a JSON struct.
-Eg:
+An easy to parse JSON structure.
 
-```
+```json
 {
-  "request_url":"http://....",
-  "params": {
-    "blog_name": "yeezy"
+  "request_url": "http://....",
+  "call_id": "abc123",
+  "method": "GET",
+  "body": {
+    "some": "input"
+  }
+}
+{
+  "request_url":"http://....",
+  "call_id": "edf456",
+  "method": "GET",
+  "body": {
+    "other": "input"
   }
 }
-BLANK LINE
-BODY
 ```
 
 Pros:
 
 * Streamable
-* Easy to parse headers
+* Easy to parse
 
 Cons:
 
-* New, unknown format
+* ???
 
-### STDERR
+## Output
+
+### Output back to client
+
+Typically JSON is the output format and is the default output, but any format can be used.
+
+### Logging
 
 Standard error is reserved for logging, like it was meant to be. Anything you output to STDERR will show up in the logs. And if you use a log
 collector like logspout, you can collect those logs in a central location. See [logging](logging.md).