[Development] API review for a new QDnsResolver class

[Jeremy Lainé]

On 11/04/2011 09:37 PM, Thiago Macieira wrote:
> On Friday, 4 de November de 2011 21:01:30 Andre Somers wrote:
>> Me too. My point was, that we have slightly different patters for
>> basically the same sort of thing in different places in Qt. QFuture is
>> currently coupled with QtConcurrent, but is there a strong reason why
>> is must be? I was not privy to that IRC chat, perhaps you could tell us
>> the reasoning why it would not be possible?
> There's no reason why it has to be coupled with Concurrent. Or, to put in
> other words, it could be changed to work without Concurrent.
>
> However, the problem is, it is currently too tightly coupled with
> QtConcurrent. Unless someone is volunteering to do this work right now...
>

OK so to sum up:

- the QNAM-style API seems to be OK

- I have implemented QDnsReply::abort() to cancel a lookup request

- Robin mentioned adding a static QDnsResolver::instance() method, does anyone else have 
an opinion on this?

- concerning QDnsReply ownership:

  * using QSharedPointer<QDnsReply> doesn't really help, it breaks QNAM expectations by 
making the user needs to hold an explicit reference to the reply

  * QFuture would be interesting, but it won't be split from QtConcurrent in the 
foreseable future

  * as a fallback I propose we stick with the same reply ownership model as QNAM (i.e. the 
reply is initially owned by the QDnsResolver, but the user can use setParent), it has the 
advantage of being well-known

Unless there are any objections I will push the reworked QDnsResolver to gerrit.

Jeremy