On 3/19/07, Ryan Phillips <[EMAIL PROTECTED]> wrote:
Hi All!
I needed an APR DNS query interface, so I wrote one. After Paul
Querna's suggestion for me to use the c-ares library, I came up with the
following code:
http://svn.trolocsis.com/repos/projects/apr_dns_query/trunk
I haven't written the patches to change APR's autoconf system -- yet.
And I have been thinking that it would be nice to abstract the DNS library
out, so the code doesn't rely strictly on c-ares.
I wanted to elicit everyone's opinions on the direction of this piece
of code.
My goal is to get this placed into apr-util proper, if this is the
consensus.
I definitely like the idea of an async-dns wrapper in APR, but I have
a few questions about the approach here.
Using c-ares means that it's essentially impossible to integrate an
async DNS request with an apr_pollset based main loop, since IIRC
c-ares is pretty wedded to its own internal select. Now, I can
envision some sort of timeout based apr_dns_poll function, so you
could alternate back and forth with the actual apr_pollset_poll, but
if you had a DNS implementation that worked with apr_pollset_t
natively (well, more likely with apr_pollcb_t) it'd be much easier to
integrate into a larger application.
I'm not sure how I feel about adding YADOAEL (yet another dependency
on an external library). I mean yeah, c-ares is tiny, but it's also
not necessarily on every system...
I do agree that moving to an interface that's more abstract, as
opposed to exposing all sorts of c-ares constants in the API would
make a lot of sense.
-garrett
