[getdns-api] 0.268 srv_addresses not useful

[Phil Pennock]

On 2013-01-31 at 13:23 -0800, Paul Hoffman wrote:
> Proposed:
> 
> <p>The API can make service discovery through SRV records easier. If the <code>request_type</code>
> in the call was for SRV records, the top level of <code>replies_tree</code> has two additional names,
> <code>srv_addresses_all</code> (a list) and <code>srv_addresses_selected</code>.
> The <code>srv_addresses_all</code> list is ordered by priority and weight based on the weighting
> algorithm in RFC 2782), lowest priority value first. The <code>srv_addresses_selected</code> list
> is similar to the <code>srv_addresses_all</code> list, except with just one address from each
> priority; the API will select this address based on a weighted probability.

I don't see the need for srv_addresses_selected because the app can do
it effectively on its own, given the other, so it seems like code for a
theoretical protocol that doesn't exist, despite that fact that some
people would like there to be a protocol which uses SRV this way.

Is there such a protocol and I've just missed it?

Either way: your API, your call, as long as the data under
srv_addresses_all is available, by some name, it's useful and my lack of
ability to see a use for the other is not a reason to block it, if
someone else wants it and the API designer is happy it fits into the
overall aesthetic.

And yes: for most normal apps, written by people who don't want to be
DNS experts, having the SRV lookup functionality will be a useful and
meaningful addition, and does not argue against something else for other
lookup types.  I've seen too much code which just took the lowest
priority entry, took one at random ignoring weights (where "random" is
"first one seen at lowest priority, with a simple loop remembering
"nope, this is lower") and used that, with no fallbacks, because SRV was
too complicated.  Some I've fixed, others I've steered clear.  A
DNS-as-needed-by-applications API should provide this; whether the API
as a whole is split into "layers", or the API provides plugins for
supporting extensions, or something else, or the API just supports some
useful types natively, none of that matters to the application as much
as having something sane available to return a list that can be iterated
over and knowing it will do the right thing.

-Phil