Hi Everyone, I'm Dean and I'm the co-maintainer of cpp-netlib. I would like to say thank you first for bringing cpp-netlib into this discussion. I'm excited that some people still both remember the library and actually that there was an effort to get it and Pion to become Boost.Network. The current stable release of cpp-netlib (0.11.0) is actually the last release where the library lives under the boost::network namespace. There's a full HTTP/1.0 server implementation there, and there's significant work to be done to support all of HTTP/1.1. That said if someone were willing to mentor turning cpp-netlib 0.11.0 into Boost.Network officially, I would very much be willing to help in that process (at a consultative/adviser/mentor(maybe) role). Because the code is laid out to be Boost-compliant in 0.11.0, it may be possible to bring back the Boost.Build shims and have a fork on github maintained by someone else that actually brings it into Boost library standards. Unfortunately the project is moving into a direction where we're doing mostly a rewrite for C++11/C++14 compliance, and as a proving ground for some of the standardization efforts Glyn Matthews (co-maintainer) and I would like to push forward with. The next release which we're hoping to do at the end of 2014 will be moving out of the boost::network namespace and has a very different code structure from Boost's. We've also been trying to minimize the reliance on some Boost libraries that we use for implementation, for a few reasons -- none of which is a reflection on Boost's state, but rather more for project organizational reasons. For example we've recently migrated all our tests away from Boost.Test and are working with igloo and Google's Test/Mock libraries. We're also moving to using Asio directly (not the Boost.Asio version). However as mentioned if someone would like to take cpp-netlib's 0.11.0 version and turn it into a proper Boost.Network library, I'm more than happy to make myself available for Hangouts to get the process going as quickly as possible. Thank you for your interest, and I wish you have great success in GSoC! On Fri, Mar 7, 2014 at 4:28 AM, Cory Nelson <phrosty@gmail.com> wrote:
On Fri, Feb 28, 2014 at 7:06 PM, VinÃcius dos Santos Oliveira <vini.ipsmaker@gmail.com> wrote:
Hi guys,
I'm interested in develop an asynchronous HTTP server for Boost as part of GSoC.
The design would be inspired from Node.js without the facilities or inspirations that were created to overcome JavaScript quirks and limitations.
The library would be modular to the point where you can use only small parts of it and you could also replace components that you don't like.
The library should have a small overhead to be used on embedded projects, but the modular design will allow you to use higher abstractions when such concerns don't exist. Of course it's difficult to find the "right" answer to the problem, then I'll limit the higher-abstractions to "proven" techniques and avoid controversial features. I hope to give more details in the middle of the next week.
The library will not be about writing template-driven web pages, but it will be about HTTP and you will be able to do things like video live stream via HTTP (try to do that with Django or PHP). I also intend to allow a efficient use in multithreaded environment with high-load of data (although network applications are usually I/O bound and not CPU bound). Of course it'll be possible to use WebSocket with this library too.
Another thing I want to allow is to mock HTTP requests and transparently replace parts of the stack without affecting already written code. The purpose of this feature is to allow other transport mechanism such as FastCGI and also provide a future-proof approach by better allowing HTTP/2.0 when released.
I would implement such library on top of Boost ASIO and I'd include facilities that I'm sure would work on long-term. Because the success of such project is very sensible to the chosen design, I'd limit its scope to things that I know it will work long-term. If the implementation project end up being too small, ...
Making a good, correct HTTP 1.1 parser is very non-trivial -- this is actually a pretty ambitious project for GSOC. I'd recommend condensing your idea as much as possible and working on it in cleanly separable steps. Don't get distracted by Websockets and FastCGI!
Please make the parser I/O agnostic and non-blocking (push bytes in, get a chunk of a http message as a result or request for more data) -- it'll be simpler to test and will allow porting to lower-level I/O when asio becomes too slow.
-- Cory Nelson http://int64.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost