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

Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-08 12:48:24

2015-08-08 11:00 GMT-03:00 Niall Douglas <s_sourceforge_at_[hidden]>:

> As a strong advocate for C++ 11 over 03 I can understand. However,
> IoT developers tend to be stuck on some pretty ancient toolsets for
> longer than others. 03 support I think would greatly increase your
> potential userbase.
>

I do care about C++03. That's why it's on the roadmap. But the design
wouldn't change noticeably and that's why I believe Boost.Http is ready for
review. Some of the requirements you're complaining about aren't Boost
requirements. Boost.Http isn't perfect now (and it'll take maybe a few
years before I exhaust my plans for improvements), but it has a strong core
that is already useful by itself. Lots of Boost libraries continued to
improve with time. It's not like you only do bugfixing after a library is
accepted.

The buck always stops with the top most layer, not internally used
> third party libraries.
>
> You NEED to fuzz test untrusted inputs when parsing HTTP. For all you
> know, your STL implementation could be the thing with the overflow
> bug, or the way in which you use it.
>

I opened an issue, so I won't forget about it:
https://github.com/BoostGSoC14/boost.http/issues/12

Ok, let's accept that HTTP before 2.0 can't multiplex (not my
> experience personally, but I agree it's got big gotchas before 2.0).
>
> You need a user facing API for Http which lets user code multiplex
> where that is available, and not multiplex when that is not
> available. In other words, identical code written against Http must
> automatically be optimal in either connection case.
>

Current design already supports concurrent requests. Each socket is a
communication channel with your application and every time you can handle
another request, you open a new socket where you'll do it. That's my plan
for HTTP 2.0. The advantage is that you don't need to associate any id with
every message (that's more lightweight and more portable against different
HTTP backends).

It could be this queue socket concept of yours is exactly what I just
> proposed as two completion handler and reactor layers. In either
> case, I don't think queue sockets should be a concept, I think they
> need to be the core of your library's user facing API.
>

And then you aren't following C++ rule number #1 anymore: You only pay for
what you use. That's why Asio itself doesn't solve this problem for you.
You can use boost::http::basic_socket<queue_socket> if you need to work
around Asio composed operations at this level. All customization points are
there for anyone.

The queue socket is mentioned in the first page (the front) of
documentation: https://boostgsoc14.github.io/boost.http/#boost_http.f0

Interesting links to follow:

   - http://sourceforge.net/p/asio/mailman/message/32259256/
   -
   http://sourceforge.net/p/axiomq/code/ci/master/tree/include/axiomq/basic_queue_socket.hpp

>   3. What alternatives may be better suited for the user examining
> > > Http for suitability and why? i.e. make your documentation useful to
> > > people with a problem to solve, not just a howto manual.
> > >
> >
> > I don't quite understand this point.
>
> What I'm really asking is for details of when before starting Http
> you reviewed the options available and the designs they used, and
> exactly why you chose the design choices in Http you did with
> reference and comparision to prior art.
>
> Like a literature review, but for programming libraries. Does this
> make sense? It's partially for us to help us understand your choices,
> but also to help those examining Http to see if it's useful to them
> to figure out the best solution to their problem (which may be to use
> an alternative to Http).
>
> Documentation which is useful over documentation which is reference.
>

I see.

That's the entire point on the "design choices" chapter:
https://boostgsoc14.github.io/boost.http/design_choices.html

Of course I can always improve this chapter by explaining more and more.
This review is helping me gather more questions to answer, but I'm already
answering here. So you guys can just ask.

-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker