Re: boost.url review

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2022-08-16 21:26:54

>
> > I would either emphasize it in the docs, or rename the containers to
> > something that reflects this fact (e.g. const_params and mutable_params,
> > as asio does).
>
> I would much rather emphasize it in the docs, because writing "const"
> and "mutable" over and over is bound to be a chore. Asio gets away
> with it because the mutability of buffers is central to the role of
> asynchronous operations but I'm not so sure the same applies here.
>
> We are very happy to hear proposals for alternate container names,
> especially if they are complete proposals (give an alternative for
> each existing name) and if necessary what the url_view and url member
> functions would be renamed to.

I would suggest leaving url and url_view as-is, and replacing the "view"
part for "const" for the rest of the containers:
- params stays as is
- params_view becomes const_params
- params_encoded stays as is
- params_encoded_view becomes const_params_encoded

And so on; I'd leave the member function names as they are.

>
> > I don't know if this is a common use case, but I'd consider adding a function
> > that simplifies it (i.e. params::set_value(string_view key, string_view value).
>
> Yep, we need that! There are open questions (like what do you do if
> more than one key exists). Here is an open issue for it:
>
> <https://github.com/CPPAlliance/url/issues/412>

Just commented there.

>
> > I'm not very keen on exposing the parsing infrastructure and helper
> > functions (other than percent encoding/decoding) as public API,
> > as I think it violates the principle of API surface minimization.
>
> I feel you there but they have to go somewhere because the
> alternatives are worse. It isn't perfect, I know.

Are the functions intended to be used just by other Boost libraries,
or also the general public? If the former is the case, could they
not be separated into a BSL-licensed repository shared between
libraries and just used as a submodule? I understand you don't want
to put them into a separate Boost library because of the review process
it would involve and the overlapping it would create, but I'd say
a submodule repo could work-around it and not violate any
of the Boost guidelines (AFAIK).

>
> > The documentation is good and the reference is complete, but I miss
> > some examples.
>
> Yep. Its not easy to come up with a complete application that just
> does stuff with URLs.

I would find this useful (this builds a QR code using Google's
Infographic API):

#include <boost/url.hpp>
#include <iostream>

using namespace boost::urls;

int
main(int argc, char **argv)
{
url u ("https://chart.googleapis.com/");
u.segments().insert(u.segments().end(), "charts");
u.params().append("cht", "qr");
u.params().append("chs", "600x600");
u.params().append("chs", argv[1]);

std::cout << u << std::endl;
}

Regards,
Ruben.