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

[Dean M. B. <mik...@gm...>]

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?

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.

> 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.

> -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.

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 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. ;)

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

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.