On Tue, Nov 16, 2010 at 1:30 AM, Cliff Green <cliffg@codewrangler.net> wrote:
I agree completely. I'm writing some thin "middle-ware" networking libraries and the threading (single, pool, etc) is left completely up to the higher layers. The constructors either use an internal io_service, or take an io_service by reference, allowing (if desired) the same io_service to be shared among multiple (other) libraries.
Cool! Maybe you'd like to contribute to cpp-netlib some of these thin networking libraries? :D We'd love to get more contributions and feedback as well. The design you describe is the same design that cpp-netlib's HTTP Server template follows. Although it currently owns the io_service it uses (for simplicity of the interface) I think taking an io_service by reference as an additional constructor overload is definitely a good idea -- something I'm going to take as a suggestion from you and will implement in the upcoming 0.8 release. Thanks for the idea! :)
There's too many libraries that encapsulate a whole threading subsystem, but one of the beauties of Asio is that it decouples networking from the threading strategy, and I would hope a good, general-use HTTP library would allow the same
I agree, and this is the same philosophy that the cpp-netlib tries to follow. However, in the interest of a simple interface, some balance has to be struck to offer a nice interface that makes sense and is not cumbersome to use and thus things like an active object implementation makes the library's interface significantly simple yet the implementation efficient and powerful. Currently the asynchronous client implementation is an active object. It's really trivial to change this to be just a normal io_service-playing implementation that doesn't have its own lifetime thread -- at the cost of a simple interface. The server implementation on the other hand values the simplicity of the handler -- any complexity should be necessary and only the complexity that comes with the user's application is the acceptable complexity at this time. The asynchronous server handler interface is already complex, but only because the use cases it's designed for is considerably complex -- where potentially long-running application specific routines will be running concurrently alongside the HTTP serving duties of the library.
(in particular, one of the use cases I would expect a good general-use HTTP library to support is embedded systems with small footprints and minimal or no threading - I haven't looked at netlib in a while, so don't know how closely the HTTP portions meet this goal).
I don't have access nor experience in dealing with embedded systems, but I'd venture a guess that if you can port the whole (or most) of Boost into the platform then cpp-netlib would certainly be usable there. The only worry at this time is the dependence on <iostream> which I've read before (but have not confirmed) causes a lot of bloat for these embedded systems. Binary sizes of debug builds is also an issue with cpp-netlib because of all the template metaprogramming going on. Also, now it requires GCC 4.4 at least to build applications that use it, making it near impossible to support embedded platforms that still use older versions of GCC (2.95, 4.1.x). At any rate, thanks very much Cliff for the feedback, I hope you can take a look at cpp-netlib and hopefully you can share more insights to help shape a hopefully boost-worthy network library implementation. :) Have a good one! -- Dean Michael Berris deanberris.com