anchor.diff:  sent back or `:error` if an error is ocurred. The `:dest` property is mandatory.
   
   
  +
  +== PUSH/PULL
  +
  +This section will explain messages defined for *push*/*pull* pattern. In other words
  +it allows implement a queue like communication.
  +
  +
  +=== PUT
  +
  +This is a message that should be used for put the data to the server.
  +
  +This is the aspect of the `:put` message:
  +
  +[source, clojure]
  +----
  +{:type :put
  + :dest :some-queue
  + :data {:id 2}}
  +----
  +
  +After sending a `:put` message we should expect an `:response` message to be
  +sent back or `:error` if an error is ocurred. The `:dest` property is mandatory.
  +
  +NOTE: the server behavior is specifically not defined. It can just not block
  +and return a response or block the http connection (not clossing it) until
  +the message is accepted.
  +
  +
  +=== TAKE
  +
  +This is a message that should be used for get the data from server.
  +
  +This is the aspect of the `:take` message:
  +
  +[source, clojure]
  +----
  +{:type :take
  + :dest :some-queue}
  +----
  +
  +After sending a `:take` message we should expect an `:response` message to be
  +sent back or `:error` if an error is ocurred. The `:dest` property is mandatory.
  +
  +NOTE: the server behavior is specifically not defined. It can just not block
  +and return a response or block the http connection (not clossing it) until
  +the message is available.
  +
  +
   == PUB/SUB
   
  -This section will contain messages that are part ot the PUB/SUB scalability protocol.
  +
  +This section will explain messages defined for *publish*/*subscribe* pattern.
   
   
   === :subscribe
  
positive.code: 
  After sending a `:publish` message we should expect an `:response` message to be
  sent back or `:error` if an error is ocurred. The `:dest` property is mandatory.
  
  
  == PUSH/PULL
  
  This section will contain messages that are part ot the PUSH/PULL scalability
  protocol.
  
  
  === PUT
  
  TBD
  
  
  === TAKE
  
  TBD
  
  
  == Clients & Servers
  
negative.code: 
  === Rationale
  
  The tipical web application usually follows the api REST architecture, but the main
  problem of that is that is bound directly to the HTTP semantics that are not
  always coherent or not always clear how to use.
  
  