On Tue, Jan 21, 2020 at 4:44 AM Vinnie Falco via Boost
Is there any interest in a URL library for Boost?
Yes, interested as well. I typically rely on QUrl (which brings in QtCore) or WebSocketPP's url, but I'd prefer a nice one from you and Boost Vinnie. I had a quick look, and the first thing that jumps to my mind though is the shear number of files, in the repo, and even just the source code, for what is a small library. Do schema and host_type need their own headers, and sometimes impl/.hpp, .ipp ??? I've known people/orgs with rules like 1-class-1-file, which I find overly granular. I've a big fan of "amalgamated" libraries, especially those which are header-only, where you can drop just 1 or 2 or 3 files into your project, and build them as source with your own code. Lowers the barrier to try something tremendously. With Boost, the hurdles are high enough, I don't even try before my org updates the full 3rd party, every 2 or 3 years... I'm probably extreme, in doing the opposite of 1-class-1-file, with a pair of .h/.cpp files that are more equivalent to an entire library (worse offender is 2K .h, and 14K .cpp), but it seems to me that the proposed Boost.URL has an awful lot of source files, "just" for URL parsing. I'd have a .h/.hpp/.ipp only myself :). .h for decls and inlines only with minimum header deps, .hpp for template stuff with additional includes, .ipp/.cpp for non-tempate non-inline impls. but I'm know I'm far from mainstream here :). ---DD PS: Also saw some references to Boost.Beast in passing. PPS: Is the allocator support similar to your proposed Boost.JSON? Could that be an independent component.