[Development] API review for a new QDnsResolver class

[Jeremy Lainé]

On 11/09/2011 06:21 PM, Robin Burchell wrote:
> On Wed, Nov 9, 2011 at 6:05 PM, Jeremy Lainé<jeremy.laine at m4x.org>  wrote:
>> This talk about QtConcurrent has me wondering: do we need an asynchronous API at all?
> I really dislike synchronous APIs, even more so when they're the only
> option. Reason being that most 'normal' people won't make the effort
> to get it right, even when that effort is just creating a slot. I've
> seen this repeatedly in code like QtContacts, as well as complaining
> about things like QNAM not enabling them to make those mistakes. Now,
> while I'm a consultant, and according to the usual jokes, I get paid
> to fix other people's mistakes, I'd rather not create more
> capabilities for people to make them. ;)
>

OK, so if we only want an async API, and we can't rely on QtConcurrent, we're back to 
using QObject to emits signals. That leaves just two options:

A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString);

pro: easy to connect to the QDnsReply's signal
con: it's entirely up to the user to handle deletion. Judging by your comments above, I 
doubt you favor it?

or

B/ static QSharedPointer<QDnsReply> QDnsReply::lookup(QDnsReply::Type, QString);

pro: memory ownership is explicit
con: how used are our users to manipulating QSharedPointer with respect to signals and such?

Jeremy