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 08:40:30

On Mon, Nov 15, 2010 at 8:55 PM, Rutger ter Borg <rutger_at_[hidden]> wrote:
> On 11/15/2010 01:04 PM, Dean Michael Berris wrote:
>>
>> The documentation has also been updated to feature a brand-new
>> reference manual detailing the implementation, caveats, and public API
>> of the HTTP client and server templates.
>>
>
> It looks interesting on first sight.
>
> I'm wondering why you chose an active object pattern for implementing
> asynchronous clients, and not the proactor pattern as enabled by Asio.

The reason for this is to keep the same interface that is enabled by
the synchronous implementation. Note that the client is an active
object, but it doesn't create one thread per connection.

A new client implementation in the next release will allow for adding
a callback function and provide a thread pool to the client so that
application-specific handlers can be invoked from that thread pool
instead of on the I/O thread dedicated to Boost.Asio's io_service.

> If
> someone wants to open many connections (e.g., a web crawler), one thread per
> connection probably isn't the way to go.

Yes, but you don't need to create one thread per connection. You can
schedule a lot of requests on the same thread, put the responses on a
container, and check if each response is ready -- and only process
those responses that are ready.

The response objects hide the fact that there are futures involved and
the API remains in the "synchronous" domain, although the
implementation underneath is asynchronous.

> This issue may be related to some
> of my concerns surrounding the current client API, where I am missing the
> (non-future) async_ methods.
>

I just implemented as part of this release a 'ready(response)'
function that allows you to check whether the response returned by the
client in the asynchronous client implementation is ready. That should
suffice for the meantime until I get to implement the callback
supporting API.

> Wouldn't a name like http++ be covering better what the library does?

Not really. This is not just an HTTP client/server, another maintainer
is developing an XMPP implementation, and later I'll be developing an
ESMTP client that follows the same API that the HTTP implementation
does.

The process being followed is as prescribed by "generic programming"
where we start with a specific implementation and then lift the
generic parts out from the specific implementations.

>
> Kind regards,
>

Thanks very much for the feedback, it is very much appreciated! :)

I hope this helps!

-- 
Dean Michael Berris
deanberris.com