How about InternetAddressStorage (or just InternetAddress), since we don't like abbreviations in our code? (Or if 'in_" is short for something else, use it instead.)
On Mon, Jan 26, 2015 at 11:07 AM, Evelina Dumitrescu < evelina_dumitre...@yahoo.com.invalid> wrote: > I renamed the IP::Address class into InAddrStorage, becuase it stores the > in_addr and in6_addr info, but I decided to keep the inner class design. > > > On Friday, January 23, 2015 7:26 PM, Dominic Hamon > <dha...@twitter.com.INVALID> wrote: > > > On Thu, Jan 22, 2015 at 5:30 PM, Benjamin Hindman <b...@eecs.berkeley.edu > > > wrote: > > > > > > > 1. implementation of IPvXaddress abstraction > > > - my preference, and the implementation Evelina has under review, is a > > > single class that abstracts away the family > > > > - others have suggested an abstract 'Address' with inheritance to manage > > > the different families > > > - in general we have used composition in the existing code-base > > > - given how non-extensible the family is, it makes sense to me to > > > continue with composition > > > > > > > I like the idea of a single 'IP' class that abstracts IP. What we saw in > > the past from Evelina's reviews was both an IP and an IPAddress, at which > > point we proposed she make IPAddress be IP::Address. But only having a > > single IP class would be much much much better. > > > > > > > 2. rename of Node > > > - this has come up before, and always been determined to be > unnecessary > > > churn > > > - renaming to Address adds confusion as it is actually an address and > a > > > port > > > - 'Endpoint' could be an alternative > > > > > > > I had called this Node originally because I didn't do my homework. This > was > > my bad. C libraries always called this sockaddr. > > > ​A sockaddr doesn't have a port, as far as I know.​ > > > > > Now they've introduced a > > new structure called addrinfo to better handle IPv6 addresses. This is > not > > meant to be churn, this is better capturing the naming from the the > > underlying libraries. I didn't want to call this SocketAddress even > though > > a bunch of libraries that abstract sockaddr call it that because > ultimately > > we want to "wrap" addrinfo. Moreover, I didn't want to call it > AddressInfo > > because the 'Info' seems unnecessary and conflicts with our protobuf > naming > > scheme (where things end with the suffix 'Info', like FrameworkInfo, > > SlaveInfo, etc). Finally, man pages around these structures simply just > > call the object "address", hence Address. > > > > ​So Evelina's class that abstracts the family should probably be > network::SocketAddress or network::Address. > > The Node, on the other hand, captures an address+port which is not an > Address.​ > > > > > > > > > On Thu, Jan 22, 2015 at 1:05 PM, Evelina Dumitrescu < > > > evelina_dumitre...@yahoo.com.invalid> wrote: > > > > > > > Hey, > > > > > > > > A few weeks ago I proposed an abstraction for the IP address. > > > > There has been a long discussion on how to implement this (eg: what > > kind > > > > of pattern to use, composition/inheritance). > > > > > > > > Ben Hindman proposed a replacement of the Node class with Address and > > > > moving several network functions to the network namespace, which > > affects > > > my > > > > implementation[1]. > > > > > > > > Here are my code reviews[2] and the Jira discussion on this issue[3]. > > > > To speed up the review process, we decided to move this discussion of > > the > > > > dev mailing list so anyone can chime in. > > > > > > > > Thanks, > > > > Evelina > > > > > > > > > > > > [1] > > > > https://reviews.apache.org/r/29538/ > > > > https://reviews.apache.org/r/29540/ > > > > https://reviews.apache.org/r/29541/ > > > > > > > > [2] > > > > https://reviews.apache.org/r/29288/ > > > > https://reviews.apache.org/r/29289/ > > > > https://reviews.apache.org/r/29290/ > > > > > > > > [3] > > > > https://issues.apache.org/jira/browse/MESOS-1919 > > > > > > > > > > > > > > > > > -- > > > Dominic Hamon | @mrdo | Twitter > > > *There are no bad ideas; only good ideas that go horribly wrong.* > > > > > > > > > -- > Dominic Hamon | @mrdo | Twitter > *There are no bad ideas; only good ideas that go horribly wrong.* > > >
