|
Boost : |
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-12-09 21:33:11
Hi Mike!
On Dec 10, 2007 9:29 AM, Michael Dickey <mike_at_[hidden]> wrote:
>
> 3) I know that Dean Michael Berris has formed a group of developers
> working on a more comprehensive network protocol library for Boost
> called cpp-netlib. HTTP is one of the protocols they are working on.
> I've offered and would still be quite happy to combine efforts
> somehow, but that project still seems to have a long way to go, and a
> few people have mentioned that it may be preferable to have an
> independent library focused on HTTP.
>
You're right about working on a comprehensive network protocol
library, but there I think are a few differences with what libpion is
addressing and what cpp-netlib is trying to address. Let me try and
point these out as how I understand it (please correct me if I'm
wrong):
1. cpp-netlib primarily aims to implement a cross-platform,
header-only, standards compliant networking client library. It aims to
make using higher level application protocols easier than it currently
is on most platforms. The HTTP implementation is intended to primarily
be a client-side implementation, to make HTTP 1.0/1.1, (E)SMTP, among
other protocols available to client code with minimal intrusion : it
being a header-only library.
2. There has been initial intent to develop a server-side
implementation for HTTP in cpp-netlib which has been dropped because
there really is no single best way to implement and HTTP server --
because writing your own HTTP server usually means that you have
different trade-offs between performance and reliability not met by
those HTTP server implementations that are already out there.
3. Libpion aims to be in C++ what the Twisted framework is in Python:
a way to easily create HTTP-aware services using asynchronous
programming and non-blocking IO.
> So.. I decided to throw all this out there and see what people think.
> Should Boost have its own HTTP library, or should it be part of an
> more comprehensive network protocol library? Would it be better have
> something available sooner in Boost that works and is reliable, and
> try to resolve the overlap over time as cpp-netlib matures? Or, would
> it be better to wait and try to merge my library (or at least it's
> functionality) into cpp-netlib?
>
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.
We can discuss this on either list (cpp-netlib-devel or this one), and
it would be something worth noting. If you look at the goals for the
1.0 release of cpp-netlib, it's to come up with a simple HTTP 1.0
client interface that's header-only, easy to use, and to come up with
the base on which most of the other network protocol implementations
will build upon. The message concept and implementation is already
available and is being currently extended to support a wide array of
policies/platforms (wide character support, chunking/linking, custom
allocators, custom string implementations, etc.).
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
I hope this helps!
-- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis_at_[hidden]] [+63 928 7291459] [+1 408 4049523]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk