Fwd: Review of Boost.url

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2022-08-24 03:52:41

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