[getdns-api] data structures/arguments to getdns_hostname and getdns_hostname_sync

[Willem Toorop]

op 20-11-13 00:36, Paul Hoffman schreef:
> On Nov 19, 2013, at 3:25 PM, Melinda Shore <melinda.shore at nomountain.net> wrote:
> 
>> As specified, the address to resolve is passed into getdns_hostname
>> and getdns_hostname_sync as a dict containing an address type, encoded
>> as a string (or octet sequence - this should be made explicit if it
>> stays), and the address itself, also a bindata.  There's an awful lot
>> of memory allocation and data movement in the API and I think that
>> this (getdns_hostname) is an example of the cost/benefit tradeoff being
>> a little sketchy.  If we do hang onto the dict encoding and make the
>> address type explicit, I think the address type should be an int (i.e.
>> a constant/macro) rather than an octet sequence, but since there are
>> reliable heuristics for determining whether a given ASCII octet sequence
>> is a v4 or v6 address it strikes me as redundant to pass that in, with
>> the additional complexity and execution cost that comes from using a
>> getdns_dict rather than just a string.
> 
> If we change this from being an admittedly verbose dict to an array, for sanity's sake I would want it to be a array of either 4 or 16 octets. That is, the application prepares whatever input it has into the actual on-the-wire address and ships it. Shipping what is hopefully ASCII text, hopefully null-terminated, seems ripe for errors. With the raw address, the only possible error is "that wasn't exactly 4 or 16 byte long".

Do you propose to use struct bindata as the input type?

getdns_return_t
getdns_hostname(getdns_context_t context,
    struct getdns_bindata *address,
    struct getdns_dict *extensions,
    void *userarg,
    getdns_transaction_t * transaction_id, getdns_callback_t callbackfn);

That would be consistent with how addresses are returned in the response
dict.