[Development] API review for a new QDnsResolver class

[shane.kearns at accenture.com]

Hi Jeremy,

The API needs a way to cancel the lookup.
Following the QNetworkReply, you could have:

bool QDnsReply::isFinished() const
void QDnsReply::abort()

QHostInfo has:

void abortHostLookup(int id)

However as we're using a response object, the abort method should be part of the object.

QDnsResolver[Runnable] should interface with the private class rather than be a friend of the public class, if possible.
For example, a static factory function in the private class

I don't have a strong view on how to present the request, but if you go the QDnsRequest route, then the QDnsResolver API should be:
QDnsReply* lookup(const QDnsRequest&)

With the QDnsRequest having the functions to construct requests for different types of record.

> -----Original Message-----
> From: development-bounces+shane.kearns=accenture.com at qt-project.org
> [mailto:development-bounces+shane.kearns=accenture.com at qt-project.org]
> On Behalf Of Jeremy Lainé
> Sent: Thursday, November 03, 2011 11:40
> To: development at qt-project.org
> Subject: [Development] API review for a new QDnsResolver class
>
> Based on some initial feedback I received regarding DNS SRV support in
> Qt, I have refactored my proposed code and introduced a "QDnsResolver"
> class which I would like to submit for API review. The point of this
> class is to provide a QNAM-style asynchronous API to perform DNS
> lookups.
>
> The resolver object itself looks like:
>
> class Q_NETWORK_EXPORT QDnsResolver : public QObject
> {
>     Q_OBJECT
>
> public:
>     QDnsResolver(QObject *parent = 0);
>     ~QDnsResolver();
>
>     QDnsReply *lookupService(const QString &serviceName, const QString
> &domainName);
>
> private:
>     Q_DECLARE_PRIVATE(QDnsResolver)
> };
>
> Currently, there is only lookupService() to perform DNS SRV record
> types, but it would be easy to add lookupText() for TXT records, etc.
>
> An open question: should we have multiple lookupXXX() methods, or a
> single lookup() which takes a QDnsRequest?
>
> The reply object looks like:
>
> class Q_NETWORK_EXPORT QDnsReply : public QObject
> {
>     Q_OBJECT
>     Q_ENUMS(Error Type)
>
> public:
>     enum Error
>     {
>         NoError = 0,
>         NotFoundError = 1,
>         UnknownError = 2
>     };
>
>     enum Type
>     {
>         SrvType = 0,
>     };
>
>     ~QDnsReply();
>
>     Error error() const;
>     QString errorString() const;
>     Type type() const;
>
>     QList<QDnsServiceRecord> serviceRecords() const;
>
> Q_SIGNALS:
>     void finished();
>
> private:
>     QDnsReply(QObject *parent);
>     Q_DECLARE_PRIVATE(QDnsReply)
>     friend class QDnsResolver;
>     friend class QDnsResolverRunnable;
> };
>
> A point worth mentioning: have multiple accessors for the different
> record types gives us some nice flexibility, as for a given request
> type (SRV, TXT) we might want to return the additional information we
> received (such as A or AAAA records).
>
> What is currently missing in this class is a getter to retrieve the
> query content. It's not yet clear to me how this should be stored:
>
> - a simple option would be simply store a QString of the queried
> records, but this does not capture the need for more structured input
> (e.g serviceName / domainName for DNS SRV)
> - another option would be to have a QDnsRequest object in the spirit of
> QNAM. For DNS SRV lookups, this would allow us to keep the split
> between the "serviceName" (_service._proto) and the "domainName" which
> is currently used by lookupService()
>
> QDnsServiceRecord is a read-only QSharedData-based class which holds
> the target, port, priority, weight of a single SRV resource record.
> Additional record types can be supported by adding QDnsXXXRecord
> classes.
>
> I have pushed my local branch of qtbase to gitorious, it comes complete
> with autotests:
>
> https://qt.gitorious.org/~sharky/qt/sharkys-qtbase/commits/dns-srv-
> support
>
> Note: I can't guarantee the win32 code still compiles, there might be
> some minor tweaks due to code refactoring.
>
> Comments are most welcome!
>
> Jeremy
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.