Re: [boost] [netlib] 0.8-beta now available!

Subject: Re: [boost] [netlib] 0.8-beta now available!
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-11-15 13:08:37

On Tue, Nov 16, 2010 at 1:30 AM, Cliff Green <cliffg_at_[hidden]> 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