On Dec 9, 2007, at 6:33 PM, Dean Michael Berris wrote:
Hi Mike!
On Dec 10, 2007 9:29 AM, Michael Dickey <mike@mikedickey.com> 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.
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. 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.
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.
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.
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
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. Take care, -Mike