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: * Convenience helpers for common handlers operation.
  
  In a catacumba design (inherited from ratpack), a handler is a unit of work in
  an asynchronous handler and the context is a execution controler and local storage
  for the current request state.
  
  In other words it can be explained as "flow control" in the chain of handlers.
  
  The request process is an asynchronous pipeline of handlers that can be
  composed in different ways (as we previously seen in a router section). So the each
  handler in the pipeline has the ability to do some work and delegate the rest of
  processing to next handler in the chain.
  
  This approach allows you build different kind of modular and completelly decoupled
  handlers and compose them into a pipeline to work together.
  
negative.code: 
  === Handlers
  
  Is the fundamentar building block in the _catacumba_ toolkit and has two main types:
  
  - *Ending*: Handlers that process a request and return a response (usually named
    controller in other web frameworks or toolkits).
  - *Middle*: Handlers that does some logic but does not return any response (
    delegating that task to other handler) (usually named as middleware or decorator).
  
  The both handler types are defined in term of functions and looks identically, the
  principal change is the responsability. Let see an example:
  
  .An *ending* handler example.
  [source, clojure]
  ----
  (defn sample-ending-handler
    [context]
    "Hello World")
  ----
  
  .An *middle* handler example.
  [source, clojure]
  ----
  (defn sample-middle-handler
    [context]
    (println "hello world")
    (ct/delegate))
  ----
  
  
  ==== The ending handlers
  
  As you have seen, the examples until now are always returning a simple string that
  in fact is not very usefull in real-world use cases. The great news here is that
  return values are handled using open polymorphic abstractions that clojure offers:
  protocols.
  
  This means that you can return anything that catacumbla already has implementation
  for it or anything that yourself have implemented. Let see some examples:
  
  .Handler example that returns ring style response.
  [source, clojure]
  ----
  (defn some-handler
    [context]
    {:status 200
     :headers {}
     :body "Hello World"})
  ----
  
  .Handler example that returns catacumba's builtin response type.
  [source, clojure]
  ----
  (require '[catacumba.http :as http])
  
  (defn some-handler
    [context]
    (http/ok "Hello World"))
  ----
  
  But this is not the end, if you want to know all the different kind of handlers
  and its return types, please take a look on <<handler-types,Handler types>> section.
  
  
  ==== The middle handlers
  
  The catacumba toolkit in request/response handling perspective behaves like a
  pipeline of handlers (when only one handler is attached it will be a pipeline of
  one unique element).
  
  As you have observed in the previous example, the *middle* handler instead of
  returning a response, returns a result an opaque type that indicates to catacumba
  that this handler is not of *ending* type and forces to catacumba take the next
  handler from the pipeline and execute it. And so until *ending* handler is found
  and response is returned.
  
  There are nothing especial, the opaque object that `delegate` function returns
  just implement appropriate protocol and if you don't like the default behavior,
  you are free to implement your own.
  
  This is a little introduction to the delegation process and how the *middle*
  handlers participates on it. For in depth understanding and how you can use it
  in your application, please read the <<handler-delegation, handler delegation>>
  section.
  
  
  === Context
  
  The second thing most important in the catacumba is the *context*. It can
  be considered a central part of both: IO and the control flow (will be
  explained in advanced section).
  
  In other words it can be considered as a combination of request and response.
  
  
  ==== Response
  
  In the previous examples, we've seen how the return value is handled, but behind
  the scenes the context is responsible for interacting with both the request and
  response.
  
  Let's see the same example but interacting directly with the context using low-level
  mutable api:
  
  [source, clojure]
  ----
  