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.*
