[Development] API review for a new QDnsResolver class

[Peter Hartmann]

On 11/04/2011 10:15 AM, ext André Somers wrote:
> (...)
> The more I think about it, the more I think it is important to fix this:
> who is responsible for the lifetime of the QDnsReply object?
>
> This API does not make that clear. I like the pattern in itself (also in
> QNAM), but I do think it would be an improvement if we were to use a shared
> pointer to the reply object. That at least makes clear who has ownership of
> the object, and prevents memory leaks when people don't realize they are
> supposed to delete the object.

Good point, maybe we could return a QSharedPointer<QDnsReply>; I could 
imagine that often QNetworkReply pointers returned by 
QNetworkAccessManager are not deleted at all...

>
> Alternatively, perhaps a look at QFuture would help. QFuture is another way
> results that are not yet ready are handled in Qt, but this time it is
> returned as a value instead of as a pointer. It would be nice we could come
> up with a single approach for these kinds of things and use that all over
> the place...
>
> Another concern is the question why you need a QDnsResolver object at all.
> It only has a single method, and it does not seem to benefit from it being
> a QObject at all at the moment, unless you plan to mimick the API of QNAM
> and add signals and slots on the Resolver object itself. If not, then it
> might as well just be a static method of the class, or just a method in a
> namespace called QDnsResolver or something like that. Currently, the user
> will have to instantiate the QDnsResolver object, and call the
> lookupService method. It is not so clear what needs to happen to that
> instance after that. Can it be savely deleted again while the request is
> still running?

If we only end up with one generic method for looking up names, then we 
might not need the class. The API might not look like 
QNetworkAccessManager and friends anymore then, which would be nice, but 
is not an absolute requirement I think.

>
>
> Andre'
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011