On 28/09/2018 05:32, Vinícius dos Santos Oliveira wrote:

2018-09-28 5:58 GMT-03:00 Damien Buhl via Boost mailto:boost@lists.boost.org>:

GET <https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de86... https://nxxm.github.io/xxhr/html/namespacexxhr.html#a69bafa24d7c33b004a7de86...>( "http://httpbin.org/anything"s, on_response = [](auto&& resp) {    std::cout << resp.text; });

Use ASIO async model. Completion token as last argument. N4045[1] is a good read to get you started.

I can help review the library once you finish this small task.

[1] https://isocpp.org/files/papers/n4045.pdf

Nice catch and Thanks Vinícius for pointing that out. I've considered bringing that at the top-level of the API as one is used to with Asio, but the reason I didn't do it for now is that it requires me alot more of implementation (that I'd like to make) for the WebAssembly backend which hasn't asio. One important point for me is that this high-level API forces an asynchronous way of thinking your programs, because it is the only way to have C++ that returns CPU time to environments like a Web browser WASM implementation.

I can help review the library once you finish this small task. Cool I would enjoy it, I'll ping you back when I've integrated a completion token in the API.

-- Damien Buhl Software Developer +33 6 77 43 10 05

On 29/09/2018 21:11, Vinnie Falco via Boost wrote:

...

I would be really interested in a pre-review or some feedback I had a look and I this your library would benefit from a strong separation of concerns. For example the Beast "session backend" has code related to multi-part encodings. In my opinion this would be more useful if it was a separate, well-defined interface that had nothing to do with Beast or Asio. The same principle applies to other code in

On Fri, Sep 28, 2018 at 1:59 AM Damien Buhl via Boost wrote: the implementation, such as following redirects. Designing code to handle redirects as a set of free functions which operate on `beast::http::response` objects would be generally helpful, and as an added bonus would allow you to more easily write unit tests.

Overall this library looks like it is off to a promising start!

Regards

Thanks for this first review, indeed refactoring the session backend and extracting the bits that are too specific would make sense. Is there in Beast a way to do the multipart encoding ? Or would it be of interest if I first factor it out and implement it in a more robust way so that it may enter once Beast ? Or is multipart something you don't see in Beast ? Cheers