Re: [boost] [asio-users] [http] Formal review of Boost.Http

Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-09 06:24:39

2015-08-08 16:36 GMT-03:00 Lee Clagett <forum_at_[hidden]>:

> [...] 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_write/overload1.html
(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