[getdns-api] On multiple call types and their arguments

[Paul Hoffman]

On Feb 12, 2013, at 5:29 AM, Dan Winship <dan.winship at gmail.com> wrote:

> On 02/11/2013 06:14 PM, Paul Hoffman wrote:
>> At a high level:
>> 
>> - By separating getdns_address() from getdns(), you are asking
>>  the application programmer to care about whether or not they
>>  want to get non-DNS answers to DNS-name-like queries. Is that a
>>  good idea? When would an application *not* want a reply that
>>  was like getaddrinfo()? My gut says to only go with one of
>>  them, the one that does getaddrinfo(), but I'm open to
>>  comments.
> 
> I was assuming that 99% of the time, if you want to look up a hostname,
> you'd use getdns_address(). getdns() would mostly only be used for
> non-A/AAAA/PTR lookups. So:
> 
>  getaddrinfo() -> getdns_address()
>  getnameinfo() -> getdns_hostname()
>  res_query()   -> getdns()

Just checking if I have this correctly:

- your getdns_address() would not need arguments for address type, nor extension to say "give me both IPv4 and IPv6"
- your getdns() would be similar to what I have now, but much less likely to be used for querying addresses, but it would *not* look up non-DNS things like WINS and mDNS

>> - I don't understand the value of getdns_service()
> 
> Basically just that the spec already had special-casing for SRV lookups
> (the srv_addresses node in replies_tree), and it might be cleaner to
> split that out into its own function rather than having it as a special
> case on the generic function.
> 
> (Also I guess I'm assuming that SRV lookup is the next-most-common kind
> of DNS lookup after A/AAAA and PTR, so it's the next best candidate for
> having a simple wrapper for.)

In some sense, then, getdns_service() is just a wrapper around getdns(), yes?

--Paul Hoffman