On Mon, Jul 3, 2017 at 4:23 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Every request will need a method and a target, so having to call members to set them feels unnecessary. A constructor ought to have been provided. will fix
the drain loop is basically a requirement for every correct program, so it should have been encapsulated into a helper function. (Even though the example as written does illustrate the use of a drain_buffer.) will fix
I'm not particularly fond of the design decision to declare parts that in practice every user of the library will need as "out of scope".
<beast/http/file_body.hpp> will be a public interface
The ASIO coupling did leave me with one question, whether it would be possible for the library to accommodate OS-specific file to socket transfers such as the one provided by TransmitFile:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740565(v=vs.85).a...
The answer is: YES. I have developed a working prototype writing HTTP messages to streams synchronously and asynchronously using ::TransmitFile. This is accomplished by providing class file_body_win32 which becomes aliased to file_body on Windows. Then, overloads of the write functions are provided which work on messages with the file_body type. These write functions require boost::asio::basic_stream_socket<Protocol> for the stream, otherwise ::TransmitFile cannot be used as there is no native SOCKET object available (the implementation resorts to the regular write in this case). This behavior is entirely transparent to users. You can declare: http::request<file_body> req; Then later, call: http::async_write(stream, req, [](error_code ec){}); and everything Just Works. Windows uses ::TransmitFile and other platforms use the file_body_stdc (which uses ugly FILE* but works). This technique can be extended to interfaces specific to other platforms. The prototype is available here: <https://github.com/vinniefalco/Beast/commits/review-addendum-1> Thanks