On Wed, Oct 4, 2017 at 9:44 AM, VinÃcius dos Santos Oliveira
Could you compare this to my parser[1]?
HTTP parsing is a pretty well defined problem and if you want to have decent performance, there aren't a whole lot of different ways to write it. Looking over your code I don't see any obvious implementation mistakes although as far as the interface goes I would have made different choices, as you can see by looking at the declaration: https://github.com/boostorg/beast/blob/7fe74b1bf544a64ecf8985fde44abf88f9902... The biggest, obvious difference is that beast::http::basic_parser and beast::http::serializer are already in Boost, and have gotten extensive testing and vetting from stakeholders. It is also running on production servers that handle hundreds of millions of dollars worth of financial transactions per month.
It could be that I'm slow
I don't know if I would say that you're slow as I have not observed your workflow but a comparison is probably unfair, as I have the opportunity to work on Beast and related projects such as Boost.Buffers and Boost.HTTPKit full-time.
but I'm starting to think you like to rush design decisions.
Now that is really unfair, and ignores the enormous amount of hours not just from me but from all of the other people who participated in the design of Beast (note that I invited you to be one of those participants). Nothing about Beast was rushed, in fact for 3 months in 2016 I was blocked on the parser design because I could not figure out an elegant interface that worked with the stream algorithms and allowed the users to supply their own buffer for the body. I tried several different designs, if you look in the commit log you can find those alternate designs. Here are just a few of the design collaborations that helped to get Boost.Beast where it is at today: Progressive body reading (122 comments!) https://github.com/boostorg/beast/issues/154 Split parsing / headers first https://github.com/boostorg/beast/issues/132 Expect: 100-continue design https://github.com/boostorg/beast/issues/123 Message container constructors https://github.com/boostorg/beast/issues/13 Fields concept and allocator support https://github.com/boostorg/beast/issues/124 Refactor Body types https://github.com/boostorg/beast/issues/580 Asio deallocate-before-invoke contract https://github.com/boostorg/beast/issues/215 And this does not include over a hundred hours working with engineers from Ripple (Beast was originally designed for them) on shared code pads to create the initial container and stream algorithm ideas. Quite a lot of time went into the design of Beast in fact there was far more time spent designing than actual coding. And I couldn't have done it without the very helpful interaction with actual users of the library; Beast was shaped by the needs of stakeholders. As a reminder to everyone, the Beast pull request / issues queue is open to all and I welcome anyone who wants to participate in the design of the library to jump right in and comment on any of the issues or pull requests. You can see that there are a number of open issues that have unresolved design questions: https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aopen+label%3ADesi... Thanks!