thiagom at wanadoo.fr
Fri Dec 13 22:47:33 GMT 2002
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
>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
Size: 189 bytes
More information about the kde-core-devel