Hi Glyn, On Mon, Dec 14, 2009 at 5:20 PM, Glyn Matthews <[email protected]> wrote: > Hi Dean, > > 2009/12/14 Dean Michael Berris <[email protected]> >> >> Next I'll be working on the connection management policy that >> dispatches based on the HTTP versions and the tag parameter. The >> connection management policy will look like the following: >> >> HTTP Version | Tag | Behavior >> HTTP 1.1 | http_default_8bit_*_resolver | All requests default to >> 'Connection: close", one request one connection. >> HTTP 1.1 | http_keepalive_8bit_*_resolver | For a given host, >> connections are persistent and re-usable, unless server sends >> 'Connection: close' to a response. >> HTTP 1.1 | http_futures_8bit_*_resolver | Client becomes active >> object, results are future<basic_response<Tag> >, one request one >> connection. >> HTTP 1.1 | http_futures_pooled_8bit_*_resolver | Client becomes >> active object, results are future<basic_response<Tag> >, connections >> are pooled 2 per host. >> HTTP 1.1 | http_async_8bit_*_resolver | Client becomes active >> object, requests will have a function object parameter which handles >> streaming data, one connection per request. >> HTTP 1.1 | http_async_pooled_8bit_*_resolver | Client becomes >> active, requests will have a function object parameter which handles >> streaming data, connections are pooled 2 per host. >> > > This is difficult to read in my e-mail program. In any case, I think this > belongs on the wiki. It would be useful to provide a catalogue of all tags > on the wiki and eventually in the quickbook docs. >
Indeed. I should really use the Wiki more. I'll do this on the Trac Wiki in the meantime. I was writing this half asleep and now that I think about it I should have used an outline instead. :D >> >> Questions, comments, suggestions, and contributions would be very much >> welcome. >> > > `hello_world.cpp` can be repeated in `examples/server/hello_world.cpp` > (where it can therefore be documented in quickbook). I think that's a > really nice example, an HTTP server in C++ in less than 40 lines ;) Though > the `request_header` type is either a struct or it's using a C++0x > initializer list. > Right. The request_header is definitely just a struct (or a POD). :) I'm still thinking about moving the request/response types as nested types to the http::basic_client<...> and http::server<...> instead of namespace-level types, or merging them to work for both the client and the server. At the worst case I would make different specializations based on the tag and type-defining them as different types server_request/server_response at the namespace level. I find it a little ugly in the C++ world of namespaces, but if you have other ideas about making the naming convention more consistent I'm all ears. :D Have a great day everyone, and Glyn please look forward to a Wiki page on tags and descriptions soon. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
