anchor.diff:  (hs/session {:storage (my-storage-constructor)})
   ----
   
  -If you want implement own session storage, take a look to the :inmemory builtin one.
  +If you want implement own session storage, take a look to the `:inmemory` builtin one.
   
   
   === Context as Request
   
  -By default, the _catacumba_'s context allows you direct access to the request and response, that are
  -instances of classes defined in Ratpack. That classes allows you access to all related properties
  +By default, the _catacumba_'s context allows you direct access to the request and response, both which are
  +instances of classes defined in Ratpack. These classes allows you to access all related properties
   such as headers, the request body, the request method, etc.
   
  -But _catacumba_ at this moment offers a very limited set of helper functions for interacting with that
  -data: get/set headers and read the body (explained in previous sections).
  -
  -For compensate this, _catacumba_ comes with special chain handler that populates the context with
  +But _catacumba_ additionally offers a small set of helper functions for interacting with that
  +data: getting/setting headers and reading the body (explained in previous sections).
  +
  +To compensate for this, _catacumba_ comes with a special chain handler that populates the context with
   basic request properties such as, headers, path and method:
   
   [source, clojure]
  
positive.code:   (component/start (application-system)))
  ----
  
  Take care, each call to the `assoc-routes!` function, the server is reloaded. In the majority of
  circumstances this is completely irelevant because it is done in a application bootstrap time.
  
  For understand it better, _catacumba_ comes with an <<sse-component-example,example>> that builds a
  multiuser char using "Server-Sent events" and component, so you can experiment with real code.
  See the <<examples,examples>> section for it.
  
  
  === Launching the server
  
  As you can see in the quick start section, the main entry point for start the server is
  the `run-server` function that receives a handler and a map with options.
  
  At this moment, it has a very little subset of options that netty and ratpack offers but is good
  start point.
  
  .Supported options
  [options="header", cols="^1,^1,^2"]
  
negative.code: == FAQ
  
  [[difference-with-aleph]]
  === What is the difference between _catacumba_ and Aleph?
  
  First of all, Aleph is one of the most robust libraries in the Clojure ecosystem for building asynchronous
  servers. Here is an incomplete list of differences and motivations why I wrote _catacumba_ instead
  of using _aleph_ directly in my applications:
  
  - Aleph with manifold offers good abstractions for creating async servers but they are much too
    low level and only provide the basic building blocks. _catacumba_ intends to be a toolkit that is highly
    focused on web development by providing a good collection of features that matter to web developers.
  - I wrote _catacumba_ to have an alternative to ring and _Aleph_ that uses ring's abstractions for
    handling web requests.
  - Aleph has a good path to have an easily readable  and user friendly documentation.
  - Aleph is build on manifold streams and _catacumba_ uses reactive-streams abstractions.
  
  