Re: [boost] [http] Formal review of Boost.Http

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/