Re: Fwd: Review of Boost.url

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-24 04:06:13

> ---------- 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/88537b7177f0548623fd55ac83fee774d97025b9/include/boost/url/url_view_base.hpp#L1948>

<https://github.com/CPPAlliance/url/blob/88537b7177f0548623fd55ac83fee774d97025b9/include/boost/url/url.hpp#L334>

> 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!