This is the mail archive of the
mailing list for the glibc project.
Re: netresolve: name resolution library project announcement
- From: Pavel Simerda <psimerda at redhat dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: libc-alpha at sourceware dot org, "Carlos O'Donell" <codonell at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 2 Dec 2013 03:58:12 -0500 (EST)
- Subject: Re: netresolve: name resolution library project announcement
- Authentication-results: sourceware.org; auth=none
- References: <301225302 dot 13988967 dot 1383944927282 dot JavaMail dot root at redhat dot com> <201311300241 dot 11248 dot vapier at gentoo dot org>
----- Original Message -----
> From: "Mike Frysinger" <firstname.lastname@example.org>
> To: email@example.com
> Cc: "Pavel Simerda" <firstname.lastname@example.org>
> Sent: Saturday, November 30, 2013 8:41:10 AM
> Subject: Re: netresolve: name resolution library project announcement
> On Friday 08 November 2013 16:08:47 Pavel Simerda wrote:
> > The primary goal of the library is to provide name resolution functionality
> > for network applications without the limitations currently imposed by the
> > glibc implementation. For now I'm going to develop netresolve alongside
> > glibc's name resolution functionality but would also like to see what can
> > be done with the glibc implementation itself. That is why I started the
> > project at sourceware.org and why I'm announcing it on the glibc mailing
> > list. Looking forward to working together to make name resolution on open
> > source systems better.
> i suspect that there are many corners of the glibc code base which simply
> lack an interested maintainer, and the resolver falls into that.
I couldn't agree more. On top of that, after reading parts of the `getaddrinfo()` code, I think I also see /why/ there's nobody to look after it.
> if someone (like you perhaps?) decided to champion it, i bet
> most people would be more than happy to let you do so.
I would like to. There's a couple of issues, though. The omnipresent one is time, which is why I'm trying to make my work effective and which finally led to starting with a separate code base. Another is lack of a standardized API and standardized behavior which may prevent me from fully merging the library into glibc. Other issues are related to my lack of experience with the glibc development process and so far not so much interest (or maybe just lack of time) on the side of glibc maintainers.
Thanks for answering, I will be likewise more than happy for people interested in getting me on the right track.