Boost logo

Boost :

Subject: Re: [boost] [http] Formal review of Boost.Http
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-11 14:21:58

On 8 Aug 2015 at 18:19, Darren Cook wrote:

> > What I should have said was this: Standalone ASIO is the reference
> > Networking TS implementation for standardisation. Http is currently a
> > set of extensions to Boost.ASIO specifically when it *should* be a
> > set of extensions to the reference Networking TS implementation for
> > C++ standardisation. This is why your current design and architecture
> > is flawed, but luckily there isn't too much work to fix this by
> > finishing the port of Http to the Networking TS.
> (Q. for Niall Douglas)
> Does this change the public-facing API of the proposed Boost.http, or
> just the implementation?

A good question I considered before voicing my opinion on Http.

I don't know if this is the right answer, but my best guess is that
if cleaved tightly to the Networking TS, Http would appear in
std::experimental alongside Networking when a standalone build and
standalone ASIO is configured to be the Networking TS library. If
standalone build but standalone ASIO is just merely ASIO, Http would
appear in namespace ::asio::http. Finally, if part of Boost, Http
would appear in namespace ::boost::http, not ::boost::asio::http.

There are of course pros and cons to these namespace choices, and I'm
not strongly decided on any of the options. But I think the key point
is that Http would need to be written to not surprise the end user in
all three configurations, and that would require exceptional care in
the API design and implementation, not least in the use case where
someone combines all three configurations of Http in the same
translation unit.

I have a bit of experience in getting library APIs to appear at
multiple namespace mount points thanks to APIBind, and I'll confess I
still get occasional CI failures where I accidentally collide a
symbol in a breaking way due to an unenforced programming error. ABI
cleanliness is a pain.

I suspect, you see, that the easiest by far namespacing is always
within the asio/networking namespace. And that's a big API change
over what's proposed.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at