We've been assuming in telepathy-spec design, in at least a few places, that longer-than-default method timeouts are possible; this makes it possible to implement RequestContactList() on Conn.I.ContactList and RequestContactInfo on Conn.I.ContactInfo, for instance.
However, telepathy-qt4 doesn't allow this. On closer inspection, this is really a QtDBus bug - QDBusAbstractInterface::asyncCall and friends can't set a non-default timeout either!
It might be possible to work around this with QDBusConnection::callWithCallback for the few places where we need it.
I think the long-term solution would be for QtDBus to gain this optional argument:
QDBusPendingCall QDBusAbstractInterface::asyncCallWithArgumentList (const QString &method, const QList<QVariant> &args, int timeout = -1);
(Requiring construction of a QList<QVariant> for the unusual case is no big deal, IMO.)
The underlying bug is http://bugreports.qt.nokia.com/browse/QTBUG-11775
Due to C++ actually having optional parameters I'd really not do this on a case-by-case basis, but make the codegen emit that param in all generated proxy methods. Actually, how would it even be done case-by-case? Having an extra spec annotation for "it might take a while"? A blacklist of forever-taking methods in tp-qt4 codegen? That is, the only methods we have calling asyncCall are the auto-generated proxy D-Bus method wrappers - so any case-by-case handling would require feeding this case information somehow to the codegen.
Anyway, we'll make 0.5.0 have a timeout parameter with a default argument in the methods for forwards-compatibility, documented as being ignored until QDBus gains support for it.
Fix merged to master. Will be in 0.5.0.