[asio-users] Boost.Http added to the Boost review schedule

[Vinícius dos Santos Oliveira]

Hello,

I'm pleased to announce that Boost.Http library was added to the Boost
review schedule[1]. We're aiming to schedule the review during August, but
it might change if a good reason is presented.

Http is one of the most popular application-level protocols within the
context of network programming and it is reimplemented over and over around
C++ communities. This library, built on top of Asio, is very flexible and I
hope to be enough for all HTTP server related needs from nearly all users,
ending this unproductive practice of HTTP (re)implementation.

I'm aiming at embeddable HTTP services (e.g. embedded ReST) at first, but
the library provides a strong separation of communication channels (e.g.
the embedded HTTP server) and request-response processing (user code + HTTP
messages). The separation is done with well documented type requirements
for those wanting compile-time polymorphism and type erased abstractions
for those wanting runtime-based polymorphism.

The library exposes the HTTP power and can be used to do video live
streaming, upgrade to other protocols (e.g. WebSocket) and others. You may
find detailed and complete information on the documentation[2].

As it may impact Asio users who deal with HTTP, I encourage the member
lists to give feedback on the library (here or, preferably, through Boost
Incubator[3]).

[1] http://www.boost.org/community/review_schedule.html
[2] https://boostgsoc14.github.io/boost.http/
[3] http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460

[Igor R]

Hello,

Post by Vinícius dos Santos Oliveira
I'm pleased to announce that Boost.Http library was added to the Boost
review schedule[1]. We're aiming to schedule the review during August, but
it might change if a good reason is presented.

<...>

Post by Vinícius dos Santos Oliveira
As it may impact Asio users who deal with HTTP, I encourage the member lists
to give feedback on the library (here or, preferably, through Boost
Incubator[3]).
[1] http://www.boost.org/community/review_schedule.html
[2] https://boostgsoc14.github.io/boost.http/
[3] http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460

The library looks really nice! However, I'd appreciate if you could
clarify a couple of points:

* Did you take a look at cpp-netlib (http://cpp-netlib.org/)? What are
the advantages of Boost.Http over that library?
* One of the great advantages of Boost libraries is their wide
portability. But according to the documentation
(https://boostgsoc14.github.io/boost.http/using.html) the library
requires C++11-compliant compiler. Is such a requirement really
justified?
* If I'm not mistaken, all the Boost libs get built with Boost.Build
system and do not require CMake. Will this requirement be dropped if
the library gets accepted?


Thanks!

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
asio-users mailing list
asio-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/asio-users
_______________________________________________
Using Asio? List your project at
http://think-async.com/Asio/WhoIsUsingAsio

[Vinícius dos Santos Oliveira]

Post by Igor R
* Did you take a look at cpp-netlib (http://cpp-netlib.org/)? What are
the advantages of Boost.Http over that library?

I took a look on many projects, including cpp-netlib:
https://github.com/vinipsmaker/gsoc2014-boost/blob/master/other_frameworks.md#cpp-netlib

One difference, for instance is that Boost.Http follows the Boost.Asio
threading model, so the user can handle HTTP requests in the same thread as
all other network traffic

Boost.Http received much more attention to the design of the library (fully
async, active model, generalization on the right spots, compile-time
polymorphism for the ones worried about performance and runtime-based
polymorphism for the OO-guys and plugins, support for extension with
alternative backends, modern HTTP features...).

* One of the great advantages of Boost libraries is their wide

Post by Igor R
portability. But according to the documentation
(https://boostgsoc14.github.io/boost.http/using.html) the library
requires C++11-compliant compiler. Is such a requirement really
justified?

Support for C++98 is not a requirement for Boost inclusion.

C++11 support is justified for sane implementation, because async code can
really look like spaghetti and lambdas help a lot. For the interface, I use
enum classes, which cannot be nicely supported in a backwards-manner, and
also move semantics. I also depend on the C++11's concept of multimap[1],
cstdint, reference_wrapper and std::function. For implementation details, I
use type traits, regex, shared pointer and std::array.

If the interest in C++98 rises and compiler support don't catch up, I may
slowly port to C++98, but this is completely unnecessary for Boost
inclusion. And it's unlikely that you want to code async code without
support for lambdas.

* If I'm not mistaken, all the Boost libs get built with Boost.Build

Post by Igor R
system and do not require CMake. Will this requirement be dropped if
the library gets accepted?

CMake requirement will be dropped if library is accepted.

[1]
https://boostgsoc14.github.io/boost.http/reference/message_concept.html#reference.message_concept.notation.f0