On 8 Aug 2015 at 13:48, Vinícius dos Santos Oliveira wrote:
But the design wouldn't change noticeably and that's why I believe Boost.Http is ready for review. Some of the requirements you're complaining about aren't Boost requirements. Boost.Http isn't perfect now (and it'll take maybe a few years before I exhaust my plans for improvements), but it has a strong core that is already useful by itself. Lots of Boost libraries continued to improve with time. It's not like you only do bugfixing after a library is accepted.
All of this is true. And I am mindful I am complaining about a design choice which is specifically that you are targeting Boost before WG21. However a Boost library is about intent and purpose and philosophy as well as technical architecture and implementation. I personally believe "Boost-ness" can mean a library should not be part of Boost which is self-contradictory I know. I appreciate that cleaving more closely to the Networking TS instead of Boost.ASIO may seem like an internal implementation detail, not a design detail. But it ticks the intent and purpose and philosophy boxes for me and right now you're not ticking them. Plus, as I mentioned, you get "free" Boost compatibility via the ASIO to Boost.ASIO conversion scripts. Where I'm really at is I think if Http is accepted you're going to either have to ditch it and reimplement atop the Networking TS as Chris folds the substantial changes WG21 will force onto ASIO into Boost.ASIO, or end up refactoring Http to cleave more closely to the Networking TS anyway. I am therefore of the position it's more efficient to skip that and just cleave right now to the Networking TS.
The buck always stops with the top most layer, not internally used
third party libraries.
You NEED to fuzz test untrusted inputs when parsing HTTP. For all you know, your STL implementation could be the thing with the overflow bug, or the way in which you use it.
I opened an issue, so I won't forget about it: https://github.com/BoostGSoC14/boost.http/issues/12
Thanks for that.
It could be this queue socket concept of yours is exactly what I just proposed as two completion handler and reactor layers. In either case, I don't think queue sockets should be a concept, I think they need to be the core of your library's user facing API.
And then you aren't following C++ rule number #1 anymore: You only pay for what you use. That's why Asio itself doesn't solve this problem for you. You can use boost::http::basic_socket
if you need to work around Asio composed operations at this level. All customization points are there for anyone.
I am finding myself unconvinced by your arguments here. What stands in the way of a two layer API design? Bottom layer is racy but lowest latency. Top layer is not racy, but adds some latency. I think for the majority of HTTP users they just want it to work without surprises to a high default performance level. If you look at the history of the HTTP library support in Python you'll see what I mean - firstly, it's surprisingly easy to get a HTTP library API design wrong, even in a v2 refactor. And secondly that people need both a stupid-simple API and a more bare metal API *simultaneously* with HTTP, and therein lies the design gotcha. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/