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

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

Dean Michael Berris wrote:
> Hi John,
>
> On Mon, Jan 12, 2009 at 11:50 PM, John P. Feltz <jf...@ov...> wrote:
>   
>> This would replace get() and other applicable base post/put/del/head's.
>>
>>     
>
> Are you sure you really want to make the API's more complicated than
> it currently stands?
>
>   
In this case: Yes, and this is only the tip of the ice-berg.
> I like the idea of doing:
>
> using http::request;
> using http::response;
> typedef client<message_tag, 1, 1, policies<persistent, caching,
> cookies> > http_client;
> http_client client_;
> request request_("http://boost.org");
> response response_ = client_.get(request_);
>
> And keeping the API simple.
>   
I do not want to confuse things by trying to equate the above exactly 
with basic_client in my branch. I'll start by saying that first -from 
implementation experience, there is no such thing as a 1.1. or 1.0 
client. At best you have an old 1.0, a revised 1.0, and 1.1. The 
specifications by which this basic_client functions off of are the only 
feasible way to identify and delineate it's behavior. This is why in my 
branch this takes the form of policies which are based off of either one 
specification, or a certain combination.

Speaking of ice-bergs, while I do appreciate the original intentions of 
simplicity behind the client's API, due to expanding implementation 
concerns and overlooked error handling issues, this view might warrant 
changing. Consider the case where prior-cached connection fails: a 
connection which was retrieved from a supplier external to the 
client-with the supplier being possibly shared by other clients. This 
poses a problem for the user. If the connection was retrieved and used 
as part of a forwarded request several levels deep, the resulting error 
isn't going to be something easily identifiable or managed. While this 
is perhaps a case for encapsulating the client completely, it all 
depends on how oblivious we expect users of this basic_client to be. At 
the moment, I had planned in the next branch release that auto 
forwarding and dealing with persistent connections to be something 
removed from the basic_client. Instead a optional wrapper would perform 
the "driving" of a forwarded request and additionally encapsulate the 
connection/resolved cache. This would take the shape of your previous 
source example and I don't see this as a significant change. If this 
could be done at the basic_client level through a policy configuration 
than I would support that as well, however for _right now_, I don't see 
an easy to way to do that.
>> The deviations would be based off two criteria:
>> -The specification(ie: rfc1945) by which the request_policy processes
>> the request (it's coupled with policy)
>>     
>
> The get/put/head/delete/post(...) functions don't have to be too
> complicated. If it's already part of the policies chosen, we can have
> a default deviation as part of the signature. At most we can provide
> an overload to the existing API instead of replacing the simple API
> we've already been presenting.
>
> The goal is really simplicity more than really sticking hard to standards.
>
>   
A default is fine.
>> -In cases that, while still allowing processing of a get/post() etc,
>> would do something counter to what the user expects from the interface,
>> such as a unmatched http version or persistence.
>>
>>     
>
> Actually, if you notice HTTP 1.1 is meant to be backwards compatible
> to HTTP 1.0. At best, you just want to make the version information
> available in the response and let the users deal with a different HTTP
> version in the response rather than making the library needlessly
> complicated in terms of API.
>   
If the user receives a version that is out of spec -in many cases they 
have a strong reason not to complete a request. This is important for 
both efficiency and compliance.
> I can understand the need for the asynchronous client to be a little
> bit more involved (like taking a reference to an io_service at
> construction time and allowing the io_service object to be run
> externally of the HTTP client) and taking functions that deal with raw
> buffers or even functions that deal with already-crafted
> http::response objects. However even in these situations, let's try to
> be consistent with the theme of simplicity of an API.
>   
I have no comment regarding a-sync usage as I've not looked into that 
issue in depth, I've only tried to make existing policy functions as 
re-usable as possible for that case.
> I particularly don't like the idea that I need to set up deviations
> when I've already chosen which HTTP version I want to use -- and that
> deviations should complicate my usage of an HTTP client when I only
> usually want to get the body of the response instead of sticking hard
> to the standard. ;)
>   
A default is fine.
> If you meant that these were to be overloads instead of replacements
> (as exposed publicly through the basic_client<> specializations) then
> I wouldn't have any objections to them. At this time, I need to see
> the code closer to see what you intend to do with it. :)
>
> HTH
>
>   
Derived overloads might work, though you run into cases of un-orthogonal 
policies (at least I have with this). That would also require 
specialization and/or sub-classing of a deviation/non-deviation rfc 
policies in my branch and I would prefer to keep the current set for now.

John