Re: [cpp-netlib-devel] soliciting ideas concerning client errors

[John P. F. <jf...@ov...>]

Dean Michael Berris wrote:
> </snip>
>
> At any rate, since the basic_client is meant to be the "world-facing"
> API, it's not entirely impossible to write auxiliary classes that were
> used by a specialization of the basic_client with a different tag.
> What I mean by this is that for example, you can have a different tag
> and a different set of (new) traits and accessors from which you can
> design the basic_client specialization around.
>
> struct non_throwing_tag;
> struct persistent_connections_tag;
>
> namespace triats {
>   template <class T>
>   struct http_tag;
>
>   template <>
>   struct http_tag<non_throwing_tag> {
>     typedef http::message_tag type;
>   };
>
>   template <>
>   struct http_tag<persistent_connections_tag> {
>     typedef http::message_tag type;
>   };
> }
>
> template<>
> class basic_client<non_throwing_tag, 1, 0> {
>   // different API of a client that doesn't throw on errors
> }
>
> template<>
> class basic_client<persistent_connections_tag, 1, 0> {
>   // implement a HTTP 1.0 client that supports persistent connections
> }
>
> Internally in all these specializations, you can pretty much do
> whatever you want. ;-)
>
> Then from there (and this approach) we can essentially write unit
> tests that make sure the implementations of the specifializations do
> what they're meant to do, and then we can look into how we can merge
> the current implementation of the basic_client to accomodate or even
> leverage the work you've done into the trunk. Maybe that would then
> get us release 0.4 having an HTTP 1.1 client available. :D
>
> How does that sound to you?
>
>   
I'll look into it at the wrapper class level. I'm content with the 
current rfc family tree, from which is growth is easy, however those 
could be further decomposed and "infused" with tags to configure 
different client behavior as needed by the basic_client and wrapper.

John