-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/29529/#review69283
-----------------------------------------------------------



3rdparty/libprocess/include/process/http.hpp
<https://reviews.apache.org/r/29529/#comment113924>

    This seems like a good use of a typedef / using declaration. Is this 
something we commonly do? It can make refactoring easier in the future.



3rdparty/libprocess/src/http.cpp
<https://reviews.apache.org/r/29529/#comment113922>

    I think we can get rid of the io.hpp header here right?



3rdparty/libprocess/src/http.cpp
<https://reviews.apache.org/r/29529/#comment113927>

    This is another implicit copy that keeps the socket alive. (Same as in a 
previous review). Can we either make a comment about this or make it more 
explicit using the Socket*?



3rdparty/libprocess/src/http.cpp
<https://reviews.apache.org/r/29529/#comment113929>

    Why the choice of -1 versus the default of the function that reads till EOF?


- Joris Van Remoortere


On Jan. 2, 2015, 4:46 a.m., Benjamin Hindman wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/29529/
> -----------------------------------------------------------
> 
> (Updated Jan. 2, 2015, 4:46 a.m.)
> 
> 
> Review request for mesos, Ben Mahler, Joris Van Remoortere, and Niklas 
> Nielsen.
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> Also updated the implementation of http::get/post to be completely
> asynchronous. This refactor was made significantly easier thanks to
> the new std::string Socket::recv/send overloads.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/http.hpp 
> 9cf05acbb724ab9af8010d1788621d37a0e48e86 
>   3rdparty/libprocess/src/http.cpp 869b205656fb73edb9f02a1856d10f79ed1349b4 
> 
> Diff: https://reviews.apache.org/r/29529/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Benjamin Hindman
> 
>

Reply via email to