Re: [beast] I can't write a hello world server

From: Loup VAILLANT (l.vaillant_at_[hidden])
Date: 2024-04-09 12:46:20

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.