Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Niall Douglas's review #29

Open
3 of 18 tasks
vinipsmaker opened this issue Jan 15, 2016 · 2 comments
Open
3 of 18 tasks

Niall Douglas's review #29

vinipsmaker opened this issue Jan 15, 2016 · 2 comments

Comments

@vinipsmaker
Copy link
Member

vinipsmaker commented Jan 15, 2016

  • C++98 support.

  • Macros for C++11 (e.g. optionally expose std::error_code).

  • Remove CMake.

  • Header-only.

  • Regularly input fuzz tested. american fuzzy lop or LLVM libfuzzer at least weekly on a CI.

  • queue_socket isn't standard and causes confusion. It deserves more attention in documentation (...a page just documenting composed operations...).

  • queue_socket should be provided (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....).

  • You've not convinced me why I should use your library and not write some ad hoc code which would be "good enough".

    You've not convinced me why I should use your library and not an alternative, including one written in Python or PHP.

    At the front of your docs, you need to have me convinced by the end of page 2 that there is no better library than yours, including on other languages. Evidence such as an excellent literature review covering alternatives and benchmarks between your code and alternatives are steps in the right direction.

  • 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.

  • Benchmarks, especially latency ones which are important for many uses of HTTP are missing. I'd particularly like to know confidence intervals on the statistical distribution so I know worst case outcomes.

  • Tutorials that incrementally show how to build a full application ("Personally speaking, I'd like if in your tutorial you took ten self-contained steps in building a simple HTTP fileserver, each with a finished working program at the end of each section. Like the ASIO tutorial does. In particular, I'd like to see layers which add on etags and other of the fancy facilities in stages.").

  • HTTP/2.0.

  • CI testing with valgrind

  • thread sanitiser

  • coveralls.io coverage testing

  • Documentation improvement on the design ideas (The pipeline has the following requests... is missing and pipelining causes too much confusion still).

  • Avoid nesting too many [section] blocks.

  • easy API like the above for Python's urllib3 (example from Niall show HTTP client code).

Hints

WON'T FIX

  • Boost-less version of Boost.Http.
  • Explain why Boost.Http uses Asio.
@vinipsmaker
Copy link
Member Author

Avoid nesting too many [section] blocks.

Done, but boostbook still generates verbose TOC that I'd like to avoid.

@vinipsmaker
Copy link
Member Author

Avoid nesting too many [section] blocks.

I've just converted documentation from Boost's QuickBook to asciidoc: c535bf7

I shouldn't have troubles with QuickBook anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant