My review of Boost.URL
Before answering the questions presented by the review manager, I thought
I’d share a few words about what Boost represents to me and why I take an
interest in it.
Many moons ago, Boost was pretty much the only way to use the C++
programming language in any kind of useful, cross-platform way.
Today, the C++ standard has evolved and grown considerably. Many of the
original drivers to use Boost are seemingly “solved” in the language
itself. Notwithstanding that some of the design decisions taken by the
Committee over the years have resulted in an anaemic half-copy of Boost
features being standardised.
Because of this (in my view) failure of the committee decision process in
the face of reality, I still use many of the fundamental Boost utilities in
place of their standard counterparts.
Therefore, to my mind, Boost is still a necessary component of any
non-trivial program I write in C++.
Boost also has a collection of utility libraries, some of which have waned
in relevance over time. For example, Boost.Format is now pretty much
obsolete in the face of fmtlib (not std::format, which is another example
of a half-hearted attempt to standardise a solution).
When I program, I do so almost exclusively in C++. I don’t really want the
bother of having to reach for other languages or to stay current in their
dependency management solutions of the day. What I really want is one
massive library that I can pull in which does everything I need, or at
least the common things.
Common things for me are:
-
Communications, including HTTP, WebSockets, databases and messages buses.
-
Console IO
-
Logging
-
Graphics & Human Interfaces
-
Sound
For me, anything that takes us a step closer to having one library that
shrink-wraps all that into one `find_package` call in CMake is a win.
Now I will admit that once upon a time, I believed that all this stuff
should be in the standard library. However since then, having worked as a
library maintainer myself, I have come to realise that this is an error.
Giving compiler maintainers the burden of maintaining humongous libraries
will simply discourage innovation in compiler technology and result in
incomplete implementations and porting to new computing platforms. Boost’s
cross-platform compatibility is unparalleled.
Therefore I am strongly of the view that the place for C++ library
innovation is Boost, and the place for standardising the language changes
that are demonstrated as necessary by Boost innovation lies with the
Committee and compiler developers.
For me, any new library that increases Boost’s real-world utility, is fully
cross platform and reduces my workload when writing application programs is
very welcome.
For for the review:
> Does this library bring real benefit to C++ developers for real world
use-case?
Yes. URL parsing can be fluked with regex, split and a few hand-rolled
utilities. But why give developers the burden of hand-rolling this
boilerplate nonsense? Make simple things simple!
> Do you have an application for this library?
Absolutely. I am happy to retrofit Boost.URL into existing code and would
certainly use it in all future code.
> Does the API match with current best practices?
I have no idea what “best practices” are in API design. The API allows me
to interrogate, build and update internet URLs. I may have made different
naming choices and if I had written it I would probably have made more use
of free functions, but I’m not going to argue about style. Utility is all
that matters to me.
> Is the documentation helpful and clear?
Much like the Boost.ASIO documentation, it is 100% correct and tersely
describes the exact functionality of the API. Use of the documentation
requires at least a cursory understanding of the terms in RFC3986. Twenty
years ago, it would probably have been reasonable to require users to read
this RFC prior to using the library. Today, attention spans are shorter and
the internet is a commodity. I would prefer to see a little more narrative
and descriptions of real-world uses of some of the methods, along with code
examples.
> Did you try to use it?
Yes, I retrofitted Boost.URL into a program that I used as the basis of a
blog post - a program to demonstrate following redirect responses when
connecting a WebSocket.
I have also integrated Boost.URL into a new program which connects to an
exchange in the past week. Doing so saved probably 200 lines of hand-rolled
code.
> What problems or surprises did you encounter?
The library lacked a specific facility to extract just the HTTP TARGET
field from a URL. After reporting this to the author with a supporting use
case and hand-rolled work-arwound, this has now been added.
> What is your evaluation of the implementation?
It is clear that a great deal of care has gone into making the
implementation robust and efficient.
> How much effort did you put into your evaluation? A glance?
A quick reading? In-depth study?
I retrofitted Boost.URL into an existing program and wrote a new program
that uses the library. I spent some time discussing what I felt were
missing features with the author, who has been responsive. My required
features subsequently appeared.
> Are you knowledgeable about the problem domain?
I’ve been writing internet-facing servers and clients in C++ for a decade.
In all that time I have never read RFC3986. I suspect like 99% of
developers, I have simply inferred the rules of URL encoding through use.
So perhaps a time-served journeyman rather than domain expert.
Recommendation: ACCEPT
The day I can write a CML that has only one dependency, Boost, will be a
happy day.
--
Richard Hodges
hodges.r(a)gmail.com
office: +44 2032 898 513
home: +376 861 195
mobile: +376 380 212
