The Trouble with KExtendedSocket

[Jim B. <Bla...@yi...>]

First I would like to thank Dominique Devriese for supplying a patch to=20
support SHA1 encrypted passwords.  Not only has he helped add a valuable=20
feature, but he has got me motivated again.

KExtendedSocket has never worked with kjabber. =20
How it should work: KExtendedSocket is used as the source for a QDomDocum=
ent. =20
The QDomQodument parses the full xml tag and then we can decide what to d=
o=20
with it.  setSource takes a QIODevice, which K*Extended*Socket (eventuall=
y)=20
inherits from.  However, when QDom parses the socket, we get an error:=20
unexpected end of file on the first character, and we can never get any d=
ata=20
from the socket. =20
How it does work: QSocket (also inheriting from QIODevice) seems to be wo=
rking=20
perfectly (check out with the -D "1/21/02 10:00:00 UTC" option). =20
Why this isn't a solution: QSocket does not support SOCkS or other networ=
k=20
settings that users can specifiy and that all kde compliant programs shou=
ld=20
use. =20
Why other solutions don't work: Getting data from KExtendedSocket a diffe=
rent=20
way.  This would require passing a refrence to the readBlock funtion.  Th=
is=20
would requiring either having enough buffer size for anything the server =
will=20
throw your way or parsing the chuncks that you do grab into the buffer.  =
Now=20
the first option might be impossible for file transfers, and the second=20
option kind of defeats the purpose of using QDom for parsing.  KSock is n=
ot=20
derived from QIODevice, so we can't use that.

I would appreciate suggestions on how to work around this, or an explanat=
ion=20
of kextsock's noncompliant behavior.  Untill then, I will probably be usi=
ng=20
QSock to continue development. Thanks,

--=20
Jim Blomo