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
*- Does this library bring real benefit to C++ developers for real
Boost currently contains at least three parsers (Regex, Spirit, and
Xpressive) and most application seem to make do with std::string as a URL
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?*
* - 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk