Fixed stub for storage service. It must take abstract logger as argument of the constructor, not logging service. I forgot to fix it when made basic logger interface.
Avoid copypast and hide implementation details in special workspace. message_handler template handles everything corresponding to handling of message from service. handler_detail removes message handling from handlers realisation if it's not needed.
Improved functional handler. Instead of event name handler function takes event_t object that provides upstream. Having ustream function can send more than one chunk as answer or doesn't send chunks at all. For example, it's possible to process http requests in function with this new handler. Also in this commit default on_error method of basic_handler_t is added. I don't know why somebody may want to send error to application, so i don't want to write emty on_error method in every handler.
Merge branch 'new_handlers'
Don't close upstream in functional handler immediately after function is finished. I may want to save upstream somewhere and send something later (for example do async read from storage and write result into upstream).
Minor api changes in functional handler. Handler function takes upstream and event name instead of structure event_t, which includes them. Also i forgot to use std::forward in service_t::call.
'on(std::function...)' method of application class is deprecated because it's useless. Old versions of 'on' method have been returned for backward compatibility with old function handler. Also here are some minor codestyle changes in storage stub.
New very useful http handler. It allows to simply write handlers for events from fastcgi proxy. It can unpack request for user and simply send response. Also it hides from user writing to upstream.
Some minor changes in api of http_handler (more meaningful names of methods and constructor for http_response). Also added check if upstream is already closed in 'error' method because sending error to closed upstream leads in exception, but in asynchronous applications it's difficult to control how many times we want to response (for example we want send error on timed out answer from service and on error from service, and error from service will be received after timeout).
Updated example application. Changes are related to new functional handler API.
Fixed unpacking of http request. I thought that request is map with string values, but it may have vector of string as value (if some argument was multiple times in request).
Merge branch 'http_handler'
Split realization of some "heavy" methods from declarations of classes related to http_handler.
Release 0.10.2!
Improved API of http_request and minor improvement of http_response.

Added methods to access most request parameters (from 'meta'). Methods 'header', 'cookie' and 'arg' (old 'request', new name is more meaningful) return boost::optional now, that reflects optional nature of these values. In http_response added method set_content_type, that adds content-type header or updates if it already exists.
Make deprecation adapters usable.

Deprecation adapters are unusable because they try to bind the old
binary functions with three placeholders. Removed an extra placeholder
so that this binding might work as intended.
Merge pull request #3 from cocaine/deprecation-adapter-patch

Make deprecation adapters usable.
Make deprecation adapters usable.

Deprecation adapters are unusable because they try to bind the old
binary functions with three placeholders. Removed an extra placeholder
so that this binding might work as intended.
Service release 0.10.2-1.

This service release addresses the backward compatibility mechanics bug
which rendered it unusable.
Remove some useless methods of 'http_handler'. 'error' method sends error to engine, not http error. Also user can throw exception from handler if something fatal is occured (and worker send error to engine himself), so i think that 'error' method is confusing in http application. Also it seems that users will fill http_response themselves (this includes setting of http code), so 'ok', 'bad_request', etc methods looks useless.