[getdns-api] Changing the getdns transport options

[Willem Toorop]

A few small comments below inline.

Op 12-06-15 om 17:32 schreef sara:
> 
>> On 12 Jun 2015, at 13:22, Shane Kerr <shane at time-travellers.org
>> <mailto:shane at time-travellers.org>> wrote:
>>
>> Neel & all,
>>
>> On Thu, 11 Jun 2015 23:23:22 +0000
>> "Goyal, Neel" <ngoyal at verisign.com <mailto: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.
> 
> Thanks both for the feedback. 
> 
> Firstly the official API spec doesn’t include TLS or STARTTLS, but we
> did add these to getdns v0.2 (see below),

Note that the official API does not include get functions either.  There
is no official getdns_context_get_dns_transport function officially,
(but we do have it in our library).

> so at the very least we would
> need to carefully consider what new types to add to the old method to
> support this. But it could be just the simplest version of each option
> with no fallback. For users only interested in UDP they could then stick
> with the existing methods, but anyone wanting to anything with privacy
> would sensibly choose the new API, because it offers the ability to
> specify fallback options. 
> 
> Also note that I am arguing that the underlying TCP connection handling
> should should change too. At the moment the TCP related options are
> …TCP_ONLY  or …XX_KEEP_CONNECTIONS_OPEN. The API doesn’t currently go
> into detail about the precise difference. 
> 
> In the current getdns implementation the TCP_ONLY version does a single
> message on a TCP connection (very wasteful and only really useful for
> TC=1 fallback) and in contrast the KEEP_CONNECTIONS_OPEN option has no
> timeout associated with it all - it keeps the connections open until the
> context is destroyed. The latter is IMHO unwise because DNS servers are
> today poorly equipped to handle may long-lived connections. 
> 
> I would like to see the TCP based connection handling driven by an idle
> timeout instead (until there is a signalling mechanism for exactly how
> to behave on persistent TCP connections). Of course we can map the
> existing types to something roughly equivalent and explain all this, but
> the new 'list + timeout’ concept will be much more aligned with the
> implementation. So I think users should be at least nudged, maybe pushed
> or even forced to use them….
> 
>>
>> 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.
> 
> Minor detail, but the more recent options added in getdns 0.2 but not
> documented in the API have 2 transports:
> GETDNS_TRANSPORT_TLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN
> GETDNS_TRANSPORT_STARTTLS_FIRST_AND_FALL_BACK_TO_TCP_KEEP_CONNECTIONS_OPEN
> 
>>
>> 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.

This might not be such a big issue because the prototypes are so
different.  So, it'll be a compile error (which shouldn't take 4 hours
to solve)

> 
> Yes to both these suggestions if we go down this route.
> 
>>
>> 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).
> 
> As you can tell I am in favour of deprecating them :-)
> 
> Sara. 
> 
> 
> _______________________________________________
> getdns-api mailing list
> getdns-api at vpnc.org
> 

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