apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: apr-util async DNS wrapper
Date Mon, 19 Mar 2007 23:06:07 GMT
On 3/19/07, Ryan Phillips <ryan-apr@trolocsis.com> 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.


View raw message