[getdns-api] Changing the getdns transport options

Shane Kerr shane at time-travellers.org
Fri Jun 12 14:22:18 CEST 2015


Neel & all,

On Thu, 11 Jun 2015 23:23:22 +0000
"Goyal, Neel" <ngoyal at verisign.com> wrote:

> What about making it a new method to not break existing APIs /
> bindings - set_dns_transports (note the plural) or
> set_dns_transport_order?  Internally the old method can just call
> this w/ a single element list, and the getter can return the head of
> the list.

For the "set" operation, I like the idea of a new function, for the
compatibility reason you describe.

However, the "get" operation is a bit trickier. You probably do not
want a backward-compatible version to return the head of list if the
list has more than a single entry.

I still like the idea of having a backward-compatible version of "get",
but I think it should return an error if the list is not 1-entry long.
ETOOMANYDIMENSIONSTARDISEXTERMINATEEXTERMINATEEXTERMINATE or the like.

Also, having set_dns_transport() and set_dns_transports() with only the
's' at the end to tell them apart is the path to madness (by which I
mean 4-hour debugging sessions in the middle of the night). If this
approach is used, surely using a more radically different name is a
good idea, like set_dns_transport_order(), set_dns_transport_list(), or
the like.

A final question with the backward-compatible approach is whether you
want to recommend that developers switch to the new method or not. My
own take on it would be that there is no strong need, and if you do
make a recommendation then probably a process of deprecating the old
one needs to be undertaken (ick).

Cheers,

--
Shane
_______________________________________________
getdns-api mailing list
getdns-api at vpnc.org



More information about the spec mailing list