Hi Senthil, thanks for the kind reply.

> It seems like you are quite comfortable with C++.

I am, though I'm lagging behind the latest standard (I have given up actively 
keeping up after C++14, now I just look up what I need).


> Boost.Asio and .Beast are inherently advanced topics. The examples use quite 
> advanced C++ knowledge.

To be honest it didn't felt like they are. For the Asio and Beast 
_implementers_, sure, but the user code of the smallest examples felt 
relatively simple (though perhaps with a few tricks here and there I didn't 
know about std::enable_shared_from_this for instance). But if I'm mistaken, and 
Asio and Beast require advanced knowledge from the _user_, that's a… let's say 
a significant disadvantage.


> 1. ASIO: https://www.boost.org/doc/libs/1_79_0/doc/html/boost_asio.html

Looking it up right now, thanks.

> 2. Beast: Watch this video https://youtu.be/7FQwAjELMek at the bottom of the 
> tutorials page 
> https://www.boost.org/doc/libs/1_80_0/libs/beast/doc/html/beast/examples.html.
>  This video was a turning point for me.

I've watched it too. It did help a bit, though not as much as I'd hope. One 
little thing however felt positively alarming: 
https://www.youtube.com/watch?v=7FQwAjELMek&t=2888s
""" Write as much code as you can. The more you'll write the better you'll get 
[…]"""

As a general advice to anyone learning to program, sure. But so much effort to 
use an _HTTP library_? That's backwards. To the extent possible, the onus is on 
the _author_ to make user's life as easy as possible, it's just a better use of 
our collective cognitive resources. But maybe he was referring to deeper 
concepts like asynchronous operations, and for such transferable skills I do 
agree we users should invest time.

> 3. If you would like interactive help, join the #beast channel of the cpplang 
> slack https://cppalliance.org/slack/. They are very kind and super helpful.

I'll check it out if I can, thanks. In the mean time I have one remaining 
question:

For the application I'm currently writing, I survived until now with just 
replying immediately: get request, build respond, send, done. Soon however I 
will need to wait for messages across the internet to build my responses. Which 
is a bit of a problem. I've just tested adding an active sleep for several 
seconds in my user-side respond() function, and noticed it effectively blocked 
further requests (there was no concurrent requests). What I need is a way for 
the user-code to yield, and then resume later when it has the info it needs to 
build the response.

Is there a quick answer to that, or is this a "no royal road to Asio" situation?

Loup.
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
https://lists.boost.org/mailman/listinfo.cgi/boost-users

Reply via email to