I personally always find the naming of the posix socket api quite confusing and I can never use it without constantly checking the man pages and/or examples, so I also vote for the name “Endpoint” since it is quite clear as to what it refers.
Also like the idea of a single class. > On 23 Jan 2015, at 02:30, 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. 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. > > > 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.* >>
