---------- Forwarded message --------- From: Jon Kalb Date: Mon, Aug 22, 2022 at 11:39 AM Subject: Review of Boost.url
Thank you for taking the time to review the library!
The documentation does appear to be thorough with a bit of a gentle introduction.
We concede that the docs need more work :) There's a bit of a learning curve there.
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.
Yep. My reluctance at adding these as examples is that the resulting programs would be "too short." But this is probably Beast-era thinking. Small programs, even a `main` with less than 10 lines, are still helpful. So I will mentally adjust for more numerous, smaller examples of things that users want to do.
The “Help Card” is a brilliant design but the text in the URL syntax at the top renders improperly in my browser.
My nightmare...I converted from image to SVG thinking that the SVG would be nicer but apparently it is subject to rendering issues. I have since discovered that it renders incorrectly on my iPad. I will try to adjust the fonts, and if that fails I will place it as a pixel image instead.
But it seems to me that the tools involved represent a valid and valuable contribution to the community.
Thanks! I am in fact already using them in downstream libraries :) And they have been a godsend, I got rid of many lines of code.
I wonder if an operator<() should be defined so that urls could be used as keys out-of-the-box.
Yes that should already be there, along with the other comparisons. And the library provides a hash function object too: https://github.com/CPPAlliance/url/blob/88537b7177f0548623fd55ac83fee774d970... https://github.com/CPPAlliance/url/blob/88537b7177f0548623fd55ac83fee774d970...
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.
The "well-known schemes" are enumerated in the RFC, so we provide constants only for the ones in the RFC. They all share a special property, which is that they use the same hierarchical semantics in the path (slash-delimited segments).
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.”
Nope, char is correct - and furthermore, our CI configurations include testing on platforms where char is unsigned :) So we know that this works. Thanks!