[getdns-api] async comments (0.268)

[Dan Winship]

On 02/04/2013 09:31 PM, Matt Miller wrote:
> I personally don't have an objection to such a guarantee.  Although, in your problem example, the very quick workaround would be:

yeah, that was just the first example I came up with

>>> Each implementation of the DNS API will specify an extension function
>>> that tells the DNS context which event base is being used.
>>
>> This seems inconvenient for everyone involved except the API
>> specification author. :-)
> 
> This could probably be worded differently, but we were operating under the assumption that the first implementations would not be built into libc.  If libc were really to implement it for us, maybe it's not necessary for this setup function to be called...

It doesn't matter where getdns() is implemented; you still need to do
*something* to tell it what event loop you're using.

>> getdns() users don't want to have to write:
>>
>>  #if defined (HAVE_GETDNS_EXTENSION_SET_LIBEVENT_BASE)
>>      getdns_extension_set_libevent_base (context);
>>  #elif defined (HAVE_GETDNS_EXTENSION_SET_EVENTBASE_FOR_LIBEVENT)
>>      getdns_extension_set_eventbase_for_libevent (context);
>>  #else
>>  #error Don't know how to set up getdns() on this platform
>>  #endif

> Most of us app writers pick a single (aggregated) event dispatch camp to support and move on.  In my app, I would not have this set of defines

Note that those are both specifying libevent; the spec says that the
function that you need to call to tell getdns() to use libevent is not
standardized (both of those function names above are examples given by
the spec). Eg, maybe with the initial reference implementation of getdns
you have to call the former, and then on the version that gets
integrated into glibc you need to call the latter, and on FreeBSD you
need to call a third. So, as the spec is currently written, if you want
your app to be portable to different implementations of getdns(), then
you *do* need those defines. And that's silly.

> nor would I be concerned tremendously about UNIX (poll, epoll, kqueue, select) versus Windows (win32-ioctl, select); that's what libevent (or libuv if you prefer) does, and does well.

The app author doesn't need to care, but *something* needs to provide
the integration between getdns and libevent ( / libuv / glib / Qt /
CoreFoundation / Twisted / etc). AFAICT, the spec currently says that
the getdns implementation needs to do this all by itself, and so if your
getdns implementation doesn't know about your event loop of choice, then
you're just screwed. I'm saying it would make more sense to have a
standard API that any event loop implementation can use to integrate
itself with any getdns implementation without either of them needing to
know anything specific about the other.

>>> 1.5 Calling the API Synchronously (Without Events)

> For those of us involved since the beginning, we were heavily biased toward the asynchronous model.  Some of us fought to not have the _sync_ functions even exist (-:

Eh, they're good for simple command-line things if nothing else.

-- Dan