Potential risk of delays due to DNS in twin

Hi all, I have a problem to discuss: Before long time I prepared a patch, which is included in the commit 9e3f8a7f. It was based on a completely broken patch for KDE4 - commit c24ea2b4. Our patch works correctly, but contains one potential risk - is dependent on DNS => on the network delays. First question is, how big is this risk, because we have a patch incorporated nearly a year ago and no problems observed. The fact is that if the user will have a problem with the network, probably will not even be able to open a remote window. However, this risk actually exists. In my proposal for the integration of our patch into KDE4 was a risk discussed by KDE4 team and Martin prepared a solution where the DNS queries is executed in a separate thread - commit cbb7f575. In comparison with our patch it is quite big patch. Backport of Martin's patch is hampered by the fact that he was used QtConcurrent which is included in QT4.7 and higher. Therefore, I have a question: What next? Martin designed a simple revert our patch seems to me inappropriate. The second option is to leave our patch unchanged and also a risk. Third, that someone remakes patch to not use QtConcurrent (it is beyond my abilities). Your suggestions? Thanks for your comments and help Mentioned commits: http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=c24ea2b4aac… http://git.trinitydesktop.org/cgit/tdebase/commit/?id=9e3f8a7f0c9f2ed1125c7… http://quickgit.kde.org/?p=kde-workspace.git&a=commit&h=cbb7f5750fe… Slavek --