- Notifications
You must be signed in to change notification settings - Fork425
Make http client connection buffer size configurable#843
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
| @@ -38,19 +38,20 @@ namespace network { | |||
| namespace http { | |||
| namespace impl { | |||
| template <classTag> | |||
| template <classbuffer_type> | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I don't think this change is necessary... unless I'm missing something.
We're using theTag type to determine the character type being placed in the array definition. If anything, I suspect you want to lift the trait to determine what the buffer type should be for a given tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
My thought was that I didn't want to redefine the buffer_type in the parser, which is just a helper class. The actual buffer type is defined in the class utilizing the parser, and then just forwarded. IMHO it was redundancy introduced by mistake which enforced redefinition of exactly the same buffer type in a helper class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
True, but not in the way it's designed to use traits to dispatch on the tag. Arguably the problem is that we're hard-coding the type of the buffer instead of using the tag-based dispatch we've been using everywhere. Because this is currently an implementation detail, I think the way you've done it is fine -- but that we might want to think about the wider design of this, so that it can be applied more systematically.
At this point, since the tests pass I'm willing to merge this as-is, but something worth thinking about in the future to clean this up better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
LGTM
Thanks for approving. Maybe you could explain the concept of "using traits to dispatch on the tag" a bit more. I didn't really understand it. It would help to avoid misunderstandings in the future. |
No big deal, but I realise that the documentation for this approach has disappeared from the 0.13 docs. I found the description to the approach in the 0.8 docs, which thankfully is still in the website: http://cpp-netlib.org/0.8/tag_metafunctions.html This document describes how we can determine metafunctions that will take a tag as a parameter, then provide the appropriate type depending on the tag. This dispatch mechanism is how we allow for all sorts of customisations that are predicated around a single tag type. |
I had to find a common header to define the buffer size, so I reused macros.hpp. Also allowed myself to increase buffer size to 4096, like with the server connection.