[getdns-api] async comments (0.268)
Dan Winship
dan.winship at gmail.com
Wed Feb 6 11:46:35 MST 2013
On 02/05/2013 11:52 PM, Paul Hoffman wrote:
> On Feb 5, 2013, at 8:27 PM, Dan Winship <dan.winship at gmail.com> wrote:
>> In the short term, you might be able to hardcode the behavior of
>> getaddrinfo() on specific releases of specific OSes that you care about,
>> but that doesn't seem like a plausible long-term solution. (None of the
>> other async DNS libraries have managed to achieve this, why would getdns
>> be any different?)
>
> I'll take Wil's word for it being possible (because they have done it) over yours that it isn't. :-)
AFAICT, they have a resolver that gets the same DNS results as the
system getaddrinfo() would, but does not attempt to handle non-DNS sources.
>> I want exactly (b). (And I don't think (d) would actually work, at all.)
>
> Hrm. You went from (d) being "it will take a bunch of ugly #defines" to it not working at all.
I mean that I don't think plan (d) would lead to a world where the
majority of developers who wanted to use an async DNS library could
expect to find an implementation of getdns() that gives roughly the same
results as getaddrinfo() on their platform of choice and integrates
with their event library of choice.
>> So if there's an API that
>> lets getdns tell the local event loop what fds it cares about, then that
>> would let it integrate with libevent, libuv, GLib, Qt, Twisted, etc.
>
> If I read you correctly, I agree. Do you think that should be part of this API? If so, please sketch out what it would take.
That's what the API I suggested in my first message was
(getdns_context_set_event_loop() and all that).
I'm attaching a more concrete sketch of how it could work....
-- Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getdns.c
Type: text/x-csrc
Size: 9907 bytes
Desc: not available
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130206/f6e2970c/attachment.bin>
More information about the getdns-api
mailing list