[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-games-devel
Subject:    Re: [Kde-games-devel] Client-Master
From:       George Staikos <staikos () kde ! org>
Date:       2001-04-12 15:26:04
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]