From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2022-08-16 22:15:28
On Tue, Aug 16, 2022 at 2:27 PM Ruben Perez <rubenperez038_at_[hidden]> wrote:
> Are the functions intended to be used just by other Boost libraries,
> or also the general public?
Some enterprising folks are going to want to use them to do things
like say, parse cookies, parse URLs-within-URLs (like when you put a
whole URL in the fragment), parse a larger grammar that contains URLs,
or even just parse things that are not URLs but they are already using
Boost.URL (and Boost.Beast and Boost.JSON) for their server and the
algorithms do exactly what they want with the performance and runtime
characteristics which are ideal for the use-case.
> 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?
That is the equivalent of just making them private. Which I could
easily do, just remove them from the docs and that's that. Submodules
in boost library include/ directories don't work out too well (I'm not
sure they are even allowed).
> 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
I think my current trajectory is to leave it the way it is for now,
continue building on it in other soon to be proposed libraries to
validate the design, and continue to explore new use cases. People
keep wanting to parse things, but Beast's offerings are subpar:
The ideas in this rfc7230.hpp file are ancient and they have over time
turned into what you see in Boost.URL now. The code in Beast is
showing its age and doesn't do everything people want - I would point
them to this new code. We could even update Beast to use Boost.URL and
replace the ramshackle parsers with stuff that actually works although
I am reluctant to invest heavily in new things in Beast. On the other
hand some of the new parsers that I am writing could probably just be
copied in so there's that. For example this rule handles the legacy
"extra commas and whitespace allowed in lists" grammar which was
specified in the errata:
This could be ported directly to Beast. At some point I think I will
propose it as a separate library, and by then there will be several
downstream users so the design will have more evidence supporting it.
> I would find this useful (this builds a QR code using Google's
> Infographic API):
IDK.... that's a pretty small example that just does a printf after a
few mods to the URL... I feel like an example should have a lot more
meat on the bone. On the other hand we do need more examples...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk