Re: [cpp-netlib-devel] Comments about the HTTP client interface

[Glyn M. <gly...@gm...>]

Hi Dean,

2008/8/28 Dean Michael Berris <mik...@gm...>

>
> What I would be inclined to support is something of a request builder
> implementation, which allows for example:
>
>  http::request::builder builder("http", "www.boost.org");
>  http::request r1 = builder.create("/");
>  http::request r2 = builder.create("/some_uri?param1=value");
>  http::request r3 = builder.create("/login.php",
> "username=user&password=password");
>  http::client client;
>  http::response response = client.get(r1);
>

I'd definitely be in favour of implementing a URI builder.


> The idea here is that we should be able to encapsulate the
> connection-mapping logic in the client between domains and actual
> sockets. That means, inside the client, it may be able to hold on to
> existing connections (in HTTP 1.1 clients) and then perform the
> correct actions.
>
> The aim of the interface is to convey that:
> - the client knows how to handle the connections so you don't have to
> worry about it
> - the request object as far as you are concerned is the base unit of
> data you can use to instruct the client what to do
> - you can craft any http::request and use it with any instance of the
> client without necessarily binding the client to a single
> destination/connection
>
> If it helps, you can think of an http::client object as an
> encapsulated browser of sorts, which can perform well-crafted requests
> on the users' behalf.
>
> This breaks the existing conventions on how HTTP clients look like and
> behave -- and existing library designs. I personally think this is a
> good thing, because we're doing it from scratch anyway. ;)
>

Fair enough ;)


>
> Besides, it makes things easier for developers (I think) because it
> allows a more consistent way of thinking about crafting HTTP requests
> and asking a client to perform a request on their behalf -- as
> compared to being encumbered with the notion that an http::connection
> is bound to a certain destination and that a request object is
> associated with a URI instead of being a fully-encapsulated HTTP
> request.
>

I agree, I think this is an improvement on other HTTP libs that I've used
(as I hoped it should be).  There's still more testing that needs to be done
to ensure that this really is as a robust approach as we want to claim.

Thanks for the detailed explanation,
Glyn