Hi Peter, On 11/01/2011 11:27 AM, Peter Hartmann wrote: > While I like the API and the naming proposed by Shane, I wonder if we need > some more > general API for doing other DNS lookups, like e.g. TXT records or the new > record types > needed for DNSSEC? > Could we maybe have an overload for QHostInfo::lookupHost() instead of a new > class, or > would that be to generic when it comes to parsing the response?
I am convinced the results of the different DNS lookup types need to be stored in different classes (QDnsServiceInfo, QDnsTextInfo..), as the resulting records have very different fields (take at look at RFC1035 vs RFC2782). I don't have a strong opinion regarding where the static methods used for lookup (Qxxx::lookupXXX) live, but "lookupHost" would be inacurate for service records. While we are on the topic of the API, one thing which needs to be adressed is the kind of "handle" (if any) we return for asynchronous lookups: - QHostInfo::lookupHost() returns an integer - QDnsServiceInfo::lookupService() currently doesn't return anything If I recall correctly, Thiago was not happy with returning an integer, stating a "more modern API" should be used. Are we talking about replacing QDnsServiceInfo with a QDnsServiceReply* ? Pro: it's consistent with QNAM. Con: we place the burden of freeing memory on the user. > Regarding Olivier's comment: I'd rather prefer the low-level API. I > understand the point > of convenience when having that logic in a connect() call, however I am not > convinced it > covers all the use cases: > > * Maybe at some point you might want to parse DNS responses "by hand" (e.g. > for DNSSEC?) > * Some anti-virus software apparently stores versioning information directly > in DNS > responses so the client does not need to contact the server all the time > * another (admittedly creative) example of using DNS TXT records is the > Google > certificate checker at -> > http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html > Same here, I think the low-level API needs to exist, but I am not opposed to building some convenience logic on top of it. Jeremy _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
