Seg, 2010-11-15 às 21:40 +0800, Dean Michael Berris escreveu:
On Mon, Nov 15, 2010 at 8:55 PM, Rutger ter Borg <rutger@terborg.net> 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!
The thread pool is a BAD IDEA. I'm very interested in your library, I would like to use it with other async services I have implemented using Boost Asio. For this a need to specify which io_service your library is going to use and no threads whatsoever. I like the idea of boost Asio, having a single io_service where I can put as many threads to run as I would like (this would usually be a number of threads equal to the number of cores).