On Tue, Aug 16, 2022 at 2:27 PM Ruben Perez
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: https://github.com/boostorg/beast/blob/76043dec2cf67a2ba33b32bdcc129f5f0027b... 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... Thanks