KExtendedSocket oddities

[Thiago Macieira]

Malte Starostik wrote:
>On Friday 13 December 2002 21:27, Thiago Macieira wrote:
>> Suggestion noted. IMO, setBindXXX() and setXXX() should then instead do
>> the same job.
>>
>> Maybe for KDE4 we could rename the setXXX functions to setRemoteXXX... I'm
>> open for suggestions.
>
>That sounds like a good idea. If it's setRemoteXXX and setLocalXXX there
>probably aren't any ambiguities left.

Agreed. And as Tim Jansen said in another e-mail, there's nothing stopping us 
from adding these functions right now. They aren't virtual or anything...

>> >* setAddressReusable() does nothing when called before listen().
>> >  But that means bind() is called before one gets a chance to set
>> >  SO_REUSEADDR. Not sure if this is a problem, but I've always seen and
>> >  used SO_REUSEADDR _before_ calling bind().
>I see. Maybe setAddressReusable() could just set a flag in that case and
>listen() applies it before binding.

That's what I thought. I'll add an internal flag variable to the d pointer 
which can hold the reuse addr flag.

>Somehow I've always had bad luck with sockets in KDE/Qt. QSocket either did
>too many unexpected things or wasn't lowlevel enough for what I wanted.
>KSocket was always better but still something was missing. So now I tried
>KExtendedSocket and failed again, partially. Maybe I have too weird
>requirements *g*
>I'll think a bit more about what the exact problems were and see how I'll
> get along this time; for the TCP part it looks very promising.

I'd like to know what your requirements are. I've designed KExtendedSocket 
having in mind all possible uses, which turned out to be a backfire: the 
class got too big. The normal socket uses in kdelibs and kdebase, which I 
converted to KExtendedSocket, were taken into account, but seldom have I 
received reports for more complex situations. Yours is one of the first.

Before the release in KDE 2.2, the need for buffered sockets arose (so as to 
mimic QSocket's behaviour) and then the class got more complicated than I had 
intended it to. The initial idea was to have a separate KBufferedSocket, 
wrapping around a KExtendedSocket and a KBufferedIO (problem: both inherit 
QObject and emit signals). KExtendedSocket was intended be a low-level I/O 
only -- something like a KSocketDevice that I proposed in the last e-mail.

Anyways, something I forgot to mention in the proposal was to move the 
resolver functions to a new class, a KResolver. That could also include 
things like service names to port translation, gethostname (which has always 
been a problem), etc.

-- 
  Thiago Macieira - UFOT Registry number: 1001
 thiagom at mail.com
   ICQ UIN: 1967141  PGP/GPG: 0x6EF45358
     Registered Linux user #65028
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20021213/7424363a/attachment.sig>