malte at kde.org
Fri Dec 13 21:26:11 GMT 2002
On Friday 13 December 2002 21:27, Thiago Macieira wrote:
> Malte Starostik wrote:
> >* KSocketAddress inherits QObject, defines Q_OBJECT but doesn't have any
> > signals nor slots nor does it use any QObject functionality AFAICS. This
> > seems unneccessarily inefficient (in my situation I need to keep some
> > hundred addresses). Also it makes KSocketAddress noncopyable, IMHO it
> > would be nice to have a copyable, value-based class instead. Of course
> > this would totally break BC
> These were my first KDE classes, so I didn't know better at the time. And,
> come to think of it, I had never noticed so.
> >* KExtendedSocket of course inherits QObject...but: its ctors don't take a
> > QObject* parent argument, so one cannot use QObject's nice auto-deletion
> > feature :-(
> > Adding overloads with such a parameter wouldn't break anything, would
> > it?
> Probably not a problem. Again, it's the same problem as above: my first
> classes, so I didn't know better...
No problem really, just thought maybe there was a reason I didn't see. Well,
actually there is and a good one too.
> >* setBindXXX() doesn't work on passive sockets. This is clearly
> > documented, yet it looks unnatural to me. In most cases when you bind a
> > socket, it's a passive one. Took me a while to find out that a passive
> > socket is bound to the address set with setHost() etc. instead. IMHO they
> > should either be equivalent for passive sockets or exactly the other way
> > round as now.
> 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.
> >* 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().
> Hmm... noted. Shouldn't be hard to fix it. The reason it works that way is
> quite simple: there is no socket before KExtendedSocket::listen() is
I see. Maybe setAddressReusable() could just set a flag in that case and
listen() applies it before binding.
> >* service and host resolution works primarily on QString. The overloads
> > that take a number for the port argument use QString::number() and then
> > call the QString versions. Why is this? Isn't a simple htons() far
> > cheaper than int => QString => resolution? :-) Same for IP addresses,
> > okay here I can see this would get difficult wrt IPv6 support. Still,
> > what about overloads that take an in_addr/in6_addr and skip any host
> > resolution?
> Services and hosts should be considered strings, not numbers. Don't ask me
> to change that. That's exactly the reason I've called them "services", not
> ports. If you use a number, you lose all possibility of SRV-based name
> lookup in the future.
[snip more good reasons to use strings]
> >* It's possible to create datagram sockets, which is nice. But somehow
> > KExtendedSocket lacks wrappers around sendto() and recvfrom() to
> > actually use such a socket, getting info about a packet's source and
> > all.
> Yes, it does... I'll get around to adding those.
> Anyways, I should say that I've been planning a big rewrite in that code
> for KDE4. The idea that was proposed to me was to dump the existing KSocket
> and KServerSocket and, instead, make them be derived from QSocket and use
> the KDE functionality. That would mean adding a KSocketDevice to be derived
> from QSocketDevice. And as a part of that rewrite, it could be that
> KExtendedSocket disappears and gets instead replaced by those other classes
> -- or not. I've been meaning to post a message to ask for input on that,
> and now it seems a good time as ever.
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.
short circuit; auto accident; static electricity; struct by_lightning;
double trouble; unsigned long letter; float valve; short pants; void check;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the kde-core-devel