2015-08-08 16:36 GMT-03:00 Lee Clagett
[...] The problem is the lack of composability. If a different http::Socket concept is desired (someone not using ASIO, etc.), then the http::ServerSocket concept has to be re-implemented also since there is no other implementation.
Exactly. The obvious way is to achieve composability is to use inheritance with:
`http::basic_server_socket<Socket>` where `Socket` is a http::Socket concept. Inheritance in this situation has its drawbacks, for sure (a virtual destructor should be considered).
I don't know. The only place that I see that can be abstracted among all alternative http backends is management of read_state and write_state and some auxiliary functions to check user intent (close connection...). The auxiliary functions can be provided without a base class and the read_state and write_state code is too little to convince me it's worth. http::SocketServer implementations manipulate the state of the http::Socket
(and indirectly the asio::tcp::socket), making some actions unavailable after invoking those functions. For example, after invoking `async_write_response`, no writes on the http::Socket/http::ServerSocket or asio::ip::tcp::socket can occur until the callback is invoked because it calls asio::write on the asio::ip::tcp::socket directly. So unless I am incorrect, it is important for the users to know whats being manipulated (the effects).
The documentation points the use of composed operations: https://boostgsoc14.github.io/boost.http/reference/basic_socket.html It's akin to Asio documentation on composed operations: http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio/reference/async_wri... (i.e. "the stream performs no other [...] until this operation completes") But now that you mentioned, I see that documentation can receive some improvements on the topic. The ServerSocket concept doesn't mention that some models can make use of this restriction nor there is any trait to detect if a model makes use of composed operations. The http::ServerSocket concept requires a http::Socket to write its
messages, but does the http::ServerSocket concept need to be a refinement of the http::Socket concept? This implies a strong relationship. The current specification looks like a http::ServerTraits concept - its specifying how a http::Socket is being used in situations specific to servers. There doesn't appear to be any additional state tracking needed for the http::ServerSocket functions, which is why I suggested standalone functions (I didn't see the FileServer section). In fact implementation can be inverted; make all of the current implementations for http::ServerSocket standalone functions, and then have the default http::ServerTraits implementation call the standalone versions of the functions. The http::ServerTraits should then take a http::Socket as an argument for each of the functions. This complete de-coupling would allow someone to independently change the behavior of any related server functions, even while using the same http::Socket object.
If I understood you correctly, you're proposing that all functions should be free functions, not member-functions, then everybody can customize any type to model a ServerSocket. And then you criticize the strong relationship between Socket and ServerSocket. Asio doesn't follow this model (async_read_some is a member-function, not a free function). It does appear to be an interesting idea, but I'm not sure I'm prepared to solve this detail of customization level. The order of includes could completely change the behaviour and this is the least of the problems. Can you elaborate more, then we can discuss? And the reason behind Socket and ServerSocket is the future addition of a ClientSocket, which will be a refinement of Socket. -- VinÃcius dos Santos Oliveira https://about.me/vinipsmaker