Hi Mike! On Dec 11, 2007 3:54 AM, Michael Dickey <mike@mikedickey.com> 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@gmail.com] [+63 928 7291459] [+1 408 4049523]