Forwarded from an email I received directly. ---------- Forwarded message --------- From: Jon Kalb Date: Mon, Aug 22, 2022 at 11:39 AM Subject: Review of Boost.url To: *- Does this library bring real benefit to C++ developers for real world use-case?* Boost currently contains at least three parsers (Regex, Spirit, and Xpressive) and most application seem to make do with std::string as a URL container implementation. That said, URL parsing is a non-trivial undertaking if done right and need to be done with in a surprising number of applications (because the number of applications that simply store and/or process URLs far out numbers the number of applications that directly use URLs). Having to re-invent the wheel of URL parsing in each of these apps results in both wasted time and poorly implemented solutions. URLs are both general enough and broadly used enough that they a library such as this will be a vocabulary library. *- Do you have an application for this library?* No. * - Does the API match with current best practices?* It appears so. The designed guidelines for the library are the correct ones. The issues that would cause a library such as this to not become widely used would be: - Language version dependency is too recent. - Module dependencies - Slow build times - Relies on dynamic allocation - Relies on exceptions - Not header-only - Not suitable for minimal devices/environments This is pretty much the design requirements for the library. In particular the approaches for minimizing and even avoiding dynamic allocations and functioning with or without exceptions will remove most what would be common stumbling blocks for this library. * - Is the documentation helpful and clear?* The documentation does appear to be thorough with a bit of a gentle introduction. I’d like to see more examples of getting, setting, and removing parameters and a better explanation of how escaping is handled. I suspect there is some magic there that I’d like to understand better. The “Help Card” is a brilliant design but the text in the URL syntax at the top renders improperly in my browser. * - Did you try to use it? What problems or surprises did you encounter?* I only did a read-through of the documentation, but it was thorough enough that I found (and submitted) a few minor corrections needed in the docs. * - What is your evaluation of the implementation?* I didn’t examine the implementation. *Some additional thoughts/questions for the author:* - I read Ruben’s review and tended to agree with and appreciate his thoughts. I did however disagree about exposing the low level parsing tools. If they were not a complete general implementation due to the fact that the library only needed some use cases, so they didn’t represent a completely implemented set of functionality, then I’d be skeptical and wonder if they were well tested. But it seems to me that the tools involved represent a valid and valuable contribution to the community. - I wonder if an operator<() should be defined so that urls could be used as keys out-of-the-box. - I wonder if more scheme constants should be provided. Probably not for the entire official list, but ‘ldap’, ‘mailto’, ‘news’, and ‘telnet’ might be useful enough to include. - This is out of my area of expertise, but I wondered if there might be platforms where instead of using “char” the library should be built on “signed char” or “unsigned char.” I think the URL library should be added to the Boost Libraries. I think will be valuable to the community and the level of professionalism in its design will reflect well on Boost. Thanks. Jon