> On Nov. 24, 2014, 5:55 p.m., Jie Yu wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/ipaddress.hpp, line 14 > > <https://reviews.apache.org/r/28387/diff/1/?file=774074#file774074line14> > > > > Flying by. Do not have context. Is the plan to replace the existing > > "IP" in stout with "IPAddress"? > > Evelina Dumitrescu wrote: > No I want to use the IP class be used only for parsing - converting from > different representations of address/netmask(eg: "string representation of > address/netmask or address and netmask prefix) to the Mesos internal > one(stored in IPAddress). > IPAddress wil be just an abstraction for in_addr/in6_addr and other > functions that are using them. > > Benjamin Hindman wrote: > Can you elborate on the benefit of making net::IP just be for parsing and > other net::IPAddress "for everything else"? That's defintely not how net::IP > is used today. Having both a net::IP and net::IPAddress does not sound like a > good solution from a code readability and maintainability perspective. > > Evelina Dumitrescu wrote: > IP class is used also for the entire netlink part. The purpose of > IPAddress is to expose an abstraction for in_addr and in6_addr. Use cases: > sockaddr_in/sockaddr_in6 , inet_ntop, inet_pton, gethostbyname2_r. > > Evelina Dumitrescu wrote: > If we don't use a way for abstractization/encapsulation, how cand we > store in the IP class IPv4/IPv6 addresses? > Moreover, using in_addr or in6_addr we avoid unnecessary processing in > each callsite. > In the examples given above, we wouldn't need the netmask.
You could store in_addr and in6_addr in net::IP, just like you've proposed for IPAddress. We might need to do some more refactoring of net::IP but that shouldn't be a signficant enough reason to introduce another structure that could serve the same purpose. Moreover, it would be great to provide clean wrappers around things like inet_ntop, inet_pton, gethostbyname2_r, etc, rather than creating a C++ structure that is meant to be used with older C style interfaces. Does that make sense? This has been a piecewise process in the past, and we still have more to do, but I'd like to see all of the old C style functions we use replaced with Stout and libprocess alternatives eventually. Doing this only a handful of minutes for each function but can make using the function much more readable and often much safer as well (and possible even more composable if we make it take/return Option/Try/Result). - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28387/#review62806 ----------------------------------------------------------- On Nov. 24, 2014, 5:49 a.m., Evelina Dumitrescu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/28387/ > ----------------------------------------------------------- > > (Updated Nov. 24, 2014, 5:49 a.m.) > > > Review request for mesos and Dominic Hamon. > > > Bugs: MESOS-1919 > https://issues.apache.org/jira/browse/MESOS-1919 > > > Repository: mesos-git > > > Description > ------- > > Create an IP address abstraction such that every callsite does not need to > check the family and get the right address. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/include/Makefile.am > 00a4edd0bcde3f92630fb173aeb4fff8e9139f77 > 3rdparty/libprocess/3rdparty/stout/include/stout/ipaddress.hpp PRE-CREATION > 3rdparty/libprocess/3rdparty/stout/include/stout/net.hpp > a992bd9f7caf3abcc2c5e14519ca7e3ac045bb4b > 3rdparty/libprocess/3rdparty/stout/tests/net_tests.cpp > 425132e5d7c3770be4a5a39feea5a2f22179b871 > > Diff: https://reviews.apache.org/r/28387/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Evelina Dumitrescu > >
