anchor.diff:  The return value handler is really just a helper for people coming from ring.
   Internally, the context is the main player in IO operations.
   
  -So, the handler response is can be:
  -
  -- a *string*, will result in a response with status code 200 and "text/plain" as
  -  content type.
  -- a *ring style* hash map.
  -- a *response* type (previous example).
  -
  -The return value handling is implemented using clojure protocols, so its behavior
  -can be extended easily with user defined types.
  -
  -
  -==== Reading the request
  -
  -In the catacumba the closest thing to the request concept is a context. In fact,
  -catacumba does not has request and responses. Just a central object that handles
  -the IO (Input and Output).
  +
  +==== Request
   
   The most important thing here is that the context in a user end acts like a request
   object and allows access to the most used part of the request such as the `:body`,
  
positive.code:   (:require [catacumba.core :as ct])
    (:gen-class))
  
  (defn my-hello-world-handler
    [context]
    "Hello World")
  
  (defn -main
    [& args]
    (ct/run-server my-hello-world-handler))
  ----
  
  _Catacumba_ also comes with a little collection of <<examples,Examples>> that may
  
negative.code: [source,clojure]
  ----
  [funcool/catacumba "0.9.0"]
  ----
  
  NOTE: _Catacumba_ will only run with *JDK8* and *Clojure >= 1.7*.
  
  
  === Handlers
  
  The handler consists of a function that accepts a "context" as it's first parameter
  and returns something renderable. Let's see an example:
  
  [source, clojure]
  ----
  (defn example-handler
    [context]
    "Hello World")
  ----
  
  It looks very similar to ring hand with two main differences:
  
  * instead of request ir receives a *context* that works like request but with
    more responsabilities (explained in other sections).
  * returns a string instead of a hash-map (it is also allowed but is not mandatory,
    also explained later).
  
  
  [[quick-start-routing]]
  === Routing
  
  Now knowing how we can define handlers, the next step is define a route (http
  endpoint) for our handler. That can be done with `routes` function:
  
  [source, clojure]
  ----
  (require '[catacumba.core :as ct])
  
  (def app
    (ct/routes [[:all "" example-handler]
                [:get "foobar" example-handler]]))
  ----
  
  The `routes` function receives a vector of ordered entry points for our handlers,
  and in this example we have defined two routes for the same handler (just for
  demostration purposes):
  
  The first entry defines a `/` route for all kind of requests and the second entry
  defines a `/foobar` route only for `GET` requests for the same handler.
  
  You can read a complete documentation about catacumba's routing <<routing,here>>.
  
  
  === Run the server
  
  For run the previously defined handler, just use the `run-server` function:
  
  [source, clojure]
  ----
  (ct/run-server app {:port 3030})
  ----
  
  TIP: The `run-server` function doesn't block so you can execute it in a repl without problems.
  
  You can read more about all available options that you can pass to `run-server`
  function <<launching-the-server,here>>.
  
  
  === Put all together
  
  This is what the complete source code of the example looks like:
  
  