Re: [boost] Boost.HTTP ?

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-12-11 00:16:36

Hi Mike!

On Dec 11, 2007 3:54 AM, Michael Dickey <mike_at_[hidden]> wrote:
>
> On Dec 9, 2007, at 6:33 PM, Dean Michael Berris wrote:
>
>
> Sounds right to me.  I didn't realize cpp-netlib had decided to drop
> server-side support.  I think it makes sense though, since I agree
> that the two are very differently problems.
>

Yeah, it was some sort of consensus that pretty much said -- there
were too many ways to do server side HTTP, that's not going to be
really practical to try to cover the different tradeoffs between
performance, reliability, and scalability in a library. Plus, with the
aim of doing it 'header-only' style, the amount of effort to be put
into it doesn't make much sense (yet).

I don't mind working with libpion myself, but maybe not in the
projects I'm currently involved in. :)

> I started work on libpion with the server-side approach only in mind,
> and that is definitely its focus and strength.  However, in the 0.4.0
> (most recent) release, we did add support for client-side HTTP as
> well.  Mainly, because we wanted something better to use for our unit
> testing, and I realized that once you have a reusable HTTP parser
> (plus ASIO), it was trivial to add client-side support.
>

I'll try to take a look at the client code and see what insights
cpp-netlib may gain especially with regards to the more involved HTTP
client specific code.

> >
> > If you already have an HTTP 1.0 / 1.1 client implementation that is
> > licensed under the BSL (I see that libpion is already under the BSL)
> > and can be re-worked to use the basic_message implementation that's
> > already in cpp-netlib, then I think that would be a good start.
>
> I agree that this sounds like a good place to start.  In particular,
> with the latest release we really cleaned-up and broke out the HTTP
> parsing code (which I should say was largely based on the code in
> Christopher's ASIO http_server examples) so that it can be used for
> either requests or responses, and can even be used without networking
> code (our intention is to use it also with an HTTP sniffer).
>
> Your basic_message design is certainly cleaner and more extensible
> than our own.  We basically just have HTTPRequest and HTTPResponse
> classes that extend a base HTTPMessage class (with headers, version,
> etc).  We should be able to rework the parser so that it uses your
> classes instead, and be able to share that code between the two
> projects.
>

Sweet! Sounds like a good plan to me. We can keep the discussion here.

I plan on moving the code we currently have in the cpp-netlib project
into the sandbox, so that we can have more people who are interested
be able to work with the code we currently have. Although it's not
much, the foundation of most of the network-related stuff that I plan
on building on in the future is already available -- the
basic_message<> template has a very simple and extensible interface
which allows building algorithms around it simple and extensible.

> >
> > Yes, it's going to be a lot of work, and I still need all the help I
> > can get -- with the day job taking most of the time and attention from
> > me, it's going to be hard to put in time to code all the stuff that's
> > still in my head wanting to get out someday. I plan on putting in a
> > lot more time during the holidays here in the Philippines (that's
> > between the 25th and the 1st of January) to implement more of the HTTP
> > operations and the unit tests that need to cover the implementations
> > that need to be written. So yes, it's years of man-hours of work, and
> > there's plenty for everyone who's interested. :D
>
> Unfortunately, I'm really pressed for time as well and will probably
> not be able to do much over the next couple months.  Might be able to
> find some time though to get the ball rolling.
>

We can ask for help from people who are also interested in actually
getting this into fruition (and have the time and spare brain cycles
to be able to work on it in a volunteer effort).

Does moving the development to the boost sandbox make more sense? I
don't mind doing this, and since I'm not also personally able to
maximize the resources available from sourceforge, maybe having it in
the sandbox open it up to more people and more contributions?

Insights would be most appreciated.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]