----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/53486/#review155259 -----------------------------------------------------------
Let's include some tests alongside the new code, like we did on the response side: https://github.com/apache/mesos/commit/6ac8eb1c524dc4adbc09d20dcb8e4e31d60eeb56 Otherwise, the implementation looks good, but I would wait for the tests and gzip::Decompressor integration before shipping. Higher level thought, the implementations of request vs response decoding at a glance look exactly the same, is there an implementation difference? Have you explored merging them? E.g. ``` namespace internal { template <typename T> // We can later restrict which T's are allowed. class Decoder { ... }; } // Users only use these non-templated versions: using RequestDecoder = internal::Decoder<http::Request>; using ResponseDecoder = internal::Decoder<http::Response>; ``` - Benjamin Mahler On Nov. 4, 2016, 5:55 p.m., Anand Mazumdar wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/53486/ > ----------------------------------------------------------- > > (Updated Nov. 4, 2016, 5:55 p.m.) > > > Review request for mesos and Benjamin Mahler. > > > Bugs: MESOS-6466 > https://issues.apache.org/jira/browse/MESOS-6466 > > > Repository: mesos > > > Description > ------- > > This would become the default de facto decoder used by libprocess > and replace the existing `DataDecoder`. > > > Diffs > ----- > > 3rdparty/libprocess/src/decoder.hpp > 76dca0b272af8591880ef220ec2dc006906fbc36 > > Diff: https://reviews.apache.org/r/53486/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Anand Mazumdar > >
