anchor.diff:  (ct/set-cookies! context {:cookiename {:value "foobar" :max-age 3600}})
   ----
   
  -
  +[[routing]]
   === Routing
   
   In contrast to ring, _catacumba_ is a toolkit for web development and offers builtin
  
positive.code: _Catacumba_ is an asynchronous or non-blocking web toolkit for Clojure built on top
  of ratpack and netty drawing inspiration from ring, pedestal and ratpack.
  
  
  === Rationale
  
  I started writting this library as a research project to provide a simple, non
  obstructive (a la ring) without the constraints of the existing ring spec.
  The aim is to create a web toolkit for building asynchronous web services.
  
  Here is an incomplete list of things that _catacumba_ aims to achieve:
  
  * Allow different types of handlers by being flexible and extensible
  * Provide a simple and lightweight approach for defining asynchronous web services
    with support for different abstractions such as promises, futures, core.async,
    manifold, reactive-streams, etc...
  * Build upon abstractions with simplicity and extensibility in mind.
  * Provide built in declarative style routing.
  * Remain unopinionated and versatile.
  * Come with backpressure support out of the box.
  
  _catacumba_ is not designed:
  
  * To be a fully integrated full stack solution like Immutant or Pedestal.
  * To provide an opinionated way to structure your "bussines logic"
  * To provide all possible features that you might need.
  * To be a low level, ring based library.
  
  The result of this research project is a powerfull, lightweight, and fully
  extensible asynchronous web toolkit built on top of existing and well designed
  components such as Ratpack and Netty.
  
  
  === Project Maturity
  
  Since _catacumba_ is a young project there may be some API breakage.
  
  
  === Install
  
negative.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 pipeline 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 other parts of the
  documentation). 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.
  