From kde-games-devel Thu Apr 12 15:26:04 2001 From: George Staikos Date: Thu, 12 Apr 2001 15:26:04 +0000 To: kde-games-devel Subject: Re: [Kde-games-devel] Client-Master X-MARC-Message: https://marc.info/?l=kde-games-devel&m=98708922708490 On Thursday 12 April 2001 10:02, Burkhard Lehner wrote: > Looking in the KDE 2.1 API reference > (http://developer.kde.org/documentation/library/2.1-api/classref/kdecore/) > says that there is a new class KExtendedSocket, with a lot of nice > features. But downloading the KDE 2.1 kdelibs package > (ftp://ftp.fu-berlin.de/pub/unix/X11/gui/kde/stable/2.1/distribution/tar/ge >neric/src/kdelibs-2.1.tar.bz2) doesn't contain any such files or classes! You need the latest CVS code for the new KSocket class. > I wanted to look into the class sources, because the API documentation > doesn't mention such important features as "non blocking host lookup". Does > KExtendedSocket have something like this? QSocket has, I know for sure! And > I think one shouldn't write a program that hangs on queries to DNS > services. > > So, we again have a discussion about which socket classes to use. Here the > pro's and con's: > > KSocket: > - no non-blocking DNS lookup > - very difficult to handle incoming and outgoing data > + supports SOCKS (not build in, but as another class using KSocket) > + supports IPv6 (does it really? I'm not sure!) > - using it will mean you have to link in libkdecore KSocket uses KExtended socket now. SOCKS support is 100% transparent. > KExtendedSocket: > - so many low level functionality one never needs > -/+ does it non-blocking DNS lookup? Who can tell me? > -/+ does it buffered input and output? > + subclass of QIODevice, so QDataStream can work on it directly > + supports IPv6 > - using it will mean you have to link in libkdecore > - is there already a SOCKS class for KExtendedSocket? I don't think so > > QSocket: > + well documented, very stable > + is does non-blocking DNS lookup > + subclass of QIODevice, so QDataStream can work in it directly > - doesn't support IPv6 yet (AFAIK), but will soon, binary compatible > - doesn't support SOCKS, but a class could easily be created > + no need to link in libkdecore > > So, in my opinion, KExtendedSocket or QSocket should be the way, but since > I don't know KExtendedSocket yet, I would prefer QSocket. If you use KSocket from CVS, you're using KExtendedSocket. :) Talk to Thiago if you need more functionality and don't know where to go with it. You really should be using the code in libkdecore though. It' contains a lot of the platform independed and kde-uniformity that should be in all applications. -- George Staikos _______________________________________________ Kde-games-devel mailing list Kde-games-devel@master.kde.org http://master.kde.org/mailman/listinfo/kde-games-devel