On 9/23/16 11:50 AM, Niall Douglas wrote:
On 23 Sep 2016 at 7:58, Vinnie Falco wrote:
One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces.
Time to be mildly harsh.
I'll repeat my main observation made during the Http review:
Almost everyone here and in the wider C++ community wants somebody to take the HTTP client API from the Python Requests module (http://docs.python-requests.org/en/master/) and very closely replicate it in C++ (it need not be Python Requests specifically, just some well established highly regarded high level HTTP API battle tested over many years - the key part here is DO NOT try reinventing the wheel over well established practice).
I'm not understanding this point. Vinnie just said that it doesn't currently offer more than a minimal level of functionality. Sounds to me that you're agreeing with him
We don't care about async, memory copying, performance, use of std::string, parsing, use of ASIO, serialisation or any of that other detail until somebody gets the bloody top end API implemented and stop wasting time on these currently unimportant implementation details.
Again - I'm not getting this. What are you objecting to?
*I don't care about the quality of the implementation*. I only care, for now, about the solid design of the top level API. Once we have a working implementation of that which has passed Boost peer review, everything else will follow naturally.
Again, I'm not sure what side you're on here. But I will say that that quality of implementation is the single most important thing. There's two schools of thought here a) Get your library to some advanced stage, post it and ask for feedback before you invest a lot of effort in correctness, documentation, tests, etc. The theory is that interested parties will contribute suggestions, observations and fixes and help you along. b) Make a completely finished but minimal library including tests, good documentation, examples etc. Then hope that users try it, are happy with what it does, then clamber for more features and enhancements. c) Finish the whole damn thing The worst is a) once someone downloads/clones your library and find that it's hard to understand, has bugs or in any way frustrates you, they are lost to you forever. They'll never come back. The best of c) but that's very hard to do b) Is the best most practical approach and that most likely to lead to success. It's strongly supported by the incubator. Robert Ramey