> > I see that TTL is missing from most return structures. True, you can
> > get it for A/AAAA but not for SRV, PTR and TXT.
...
> > If not, what would be the best way to add TTL visibility? Presumably
> > much along the lines of ares_addrttl and friends for those that don't
> > have a specific structure, but what about SRV and TXT? Would adding an
> > int at the end of these structures be acceptable? (A bit klunky to
> > look at, but safe from a binary compatibility POV).
> +1 on adding TTLs in the public API.
>
> I think revamping the parsing functions is a good thing, but just adding
> struct members may be a bit unsafe.
There are a couple of things to consider here. Firstly, the parsing
functions, to my mind, are the trickiest part of the library. Touching
those has the highest risk of regression bugs.
The second issue is that the parse APIs are somewhat inconsistent in
their approach in that they sometimes take a "the DNS simply presents
rows of data" model and sometimes they look at semantic values. TXT vs
AAAA vs SOA are great examples of this disparity...
> I would support new functions to more closely return DNS data (rather
> than some high-level mangled subset of the DNS data.) That possibly
> relates to the question of how to return A/AAAA records from SRV replies
> as well.
...as you observe with A/AAAA/SRV.
In an ideal world, I'd like the API to have a clean, consistent layer
at the lower level that presents all RRs as an array of type-specific
structs which include *all* values from the respective RR. This is a
semantic free layer. The parse_aaaa and ares_addr6ttl model, if you
will.
This can be achieved with the addition of a new struct or extension of
an existing struct.
As a generalization, the APIs present as:
int ares_parse_$type_reply(inputs, struct semanticoutputs, struct rowoutputs);
Most of the types can easily fall into that, while a few need some
internal rework.
On a related note, the processing code of most of these routines is
duplicated across all the parsers.
$type_out = NULL;
/* fetch question and answer counts
/* Expand name
/* Iterate over RRs
/* Decode into type-specific struct
I hate to throw this into the mix, but a refactor of this to but the
common code, in a common place could simplify the API internals quite a
bit.
BTW. I am volunteering to write code, my biggest concerns are: a)
Making sure any sort of changes like this meet with general approval;
b) how to make patches acceptable and most importantly c) how to make
sure no regression bugs are introduced (I don't see any comprehensive
tests).
Finally, is this a dead topic and folk are being polite? I don't seem
much feedback.
Mark.
Received on 2013-07-04