On Thursday, 3 de November de 2011 15:45:31 Peter Hartmann wrote: > > An open question: should we have multiple lookupXXX() methods, or a single > > lookup() which takes a QDnsRequest? > It might make sense to have a generic method for querying any type of > DNS; but then would we need a QDnsRequest class which might be overkill > if we only support SRV and maybe TXT records short term? How complex can > a DNS query possibly get so it would justify creating an own class? I am > not sure about (one generic method plus request class) vs. (several > specific methods) yet...
The DNS query is not the problem. A query is always composed of a domain name
being queried, along with the DNS class (Internet, no one uses anything else
for real purposes) and the record type. For the record type, it's very easy to
just list all types and also say that the user can use other types from the
DNS documentation. See the ns_type enum in /usr/include/arpa/nameser.h [1].
The problem is the DNS reply. Each query type contains a different kind of data
structure that would need to be parsed. It gets very complex very quickly if
we want to present the data in a nice, C++ class.
A 4 bytes containing an IPv4 address (QHostAddress)
NS a domain name (QString)
CNAME a domain name (QString)
SOA two domain names and five integers
PTR a domain name (QString)
MX an integer and a domain name
TXT text (QString)
AAAA 16 bytes containing an IPv6 address (QHostAddress)
SRV two integers and a domain name
A6 an integer, an IPv6 address and a domain name
DNAME a domain name (QString)
TKEY, TSIG ?
And that's just listing the ones that I thought we'd like to support. CNAME
and DNAME are likely not to be the query, but they might appear as part of the
reply.
[1] a that suffers from the "creat" syndrome.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
