Dean Michael Berris wrote: > Hi John, > > On Mon, Jan 12, 2009 at 11:50 PM, John P. Feltz <[email protected]> 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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Cpp-netlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
