anchor.diff:  
   ==== Server Push
   
  -The way how this protocol offers server push is using server-sent-events. One of the
  -goodnes of using this approach is that just works over http without any additional
  -configuration in your http proxy/load balancer. (If you send messages to server just
  -use the previously defined messages).
  -
  -Let see how you can create a handler for use it:
  +The way how this protocol server side push or bi-directional communication is
  +just using websockets. Them now are widelly supported so use it directy should
  +not suppose any problem.
  +
  +You can start websocket connection from any postal handler just using the
  +`catacumba.handlers.postal/socket` function:
   
   [source, clojure]
   ----
  
positive.code:   [context {:keys [data] :as frame}]
    (let [id (:id data)
          user (repo/get-user-by-id id)]
      (pc/response user)))
  
  (defmethod myhandler [:novelty :users]
    [context frame]
    (let [status (create-new-user frame)]
      (pc/response user)))
  ----
  
  The `response` function is just a helper for create response hashmaps:
  
  [source, clojure]
  ----
  (pc/response {:foo 1})
  ;; => {:type :response :data {:foo 1}}
  ----
  
  Additionally, you can return a promise (from *promissum* library) or deferred (from
  *manifold* library). If that abstractions does not satisfies you, you can
  extend the catacumba behavior with your own types and abstractions.
  
  And finally, attach the handler on the router:
  
  
negative.code:  :data {:id 1}}
  ----
  
  NOTE: The `:type` and `:dest` keys are mandatory to be present in the frame.
  
  The messages are by default serialized using transit+json serialization format
  but the system is open to be extended with other formats. The serialization is
  completelly transparent to the user, the catacumba will do all the hard work for
  you.
  
  Knowing the frame structure, the best way to define a postal handler is using
  multimethods, because they allow easy dispatch by value:
  