2015-08-08 11:00 GMT-03:00 Niall Douglas
As a strong advocate for C++ 11 over 03 I can understand. However, IoT developers tend to be stuck on some pretty ancient toolsets for longer than others. 03 support I think would greatly increase your potential userbase.
I do care about C++03. That's why it's on the roadmap. 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. 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 Ok, let's accept that HTTP before 2.0 can't multiplex (not my
experience personally, but I agree it's got big gotchas before 2.0).
You need a user facing API for Http which lets user code multiplex where that is available, and not multiplex when that is not available. In other words, identical code written against Http must automatically be optimal in either connection case.
Current design already supports concurrent requests. Each socket is a communication channel with your application and every time you can handle another request, you open a new socket where you'll do it. That's my plan for HTTP 2.0. The advantage is that you don't need to associate any id with every message (that's more lightweight and more portable against different HTTP backends). 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
3. What alternatives may be better suited for the user examining
Http for suitability and why? i.e. make your documentation useful to people with a problem to solve, not just a howto manual.
I don't quite understand this point.
What I'm really asking is for details of when before starting Http you reviewed the options available and the designs they used, and exactly why you chose the design choices in Http you did with reference and comparision to prior art.
Like a literature review, but for programming libraries. Does this make sense? It's partially for us to help us understand your choices, but also to help those examining Http to see if it's useful to them to figure out the best solution to their problem (which may be to use an alternative to Http).
Documentation which is useful over documentation which is reference.
I see. That's the entire point on the "design choices" chapter: https://boostgsoc14.github.io/boost.http/design_choices.html Of course I can always improve this chapter by explaining more and more. This review is helping me gather more questions to answer, but I'm already answering here. So you guys can just ask. -- VinÃcius dos Santos Oliveira https://about.me/vinipsmaker