[Development] Common base class for all socket types

[shane.kearns at accenture.com]

> There is a ton of overlap between QIODevice and QAbstractSocket, but
> don't think too hard about it or else you'll drive yourself mad.

QIODevice is actually a superclass of QAbstractSocket.

> The most common functionality that is shared between QAbstractSocket
> and QLocalSocket is just the connect/disconnect functionality. Aside
> from that, yes they are both more or less just QIODevices. Lots of
> things fit the QIODevice abstraction.

Yes, and the connect functionality is different.
With a QAbstractSocket: you are connecting to an IP address (or DNS name), with the service determined by the port number.
With a QLocalSocket: you are connecting to a named service on the local machine.

> With QAbstractSockets: aside from the contradiction that is UDP, you
> are connecting to a server, IO'ing to/from it, then disconnecting (udp
> emulates this). The IO stuff all exists in QIODevice already, so
> QAbstractSocket almost seems unnecessary.

QAbstractSocket exists only because there is common code & API in the TCP and UDP sockets.
It doesn't need to be part of the public API, but it would be a fair amount of work to remove it for marginal benefit & source incompatibility.

When it comes to users' IO code, QTcpSocket and QLocalSocket have more in common than QTcpSocket and QUdpSocket
However, the signals and API for interacting with an already connected stream (or indeed an open file/process) are all in QIODevice.

> Yes QProcess and even QFile can be used to communicate with a 'server',
> but in general they are not. QNetworkReply, however, has no 'connectTo'
> analog so doesn't really fit at all. QNAM is a different networking
> model. I find it strange that QNetworkRequest doesn't also derive from
> QIODevice, but eh I don't really use QNAM all too often so I don't
> really care to think about it.

QNetworkReply derives from QIODevice.
As you say, it's a different networking model, with the purpose of fetching resources from URLs.
QNetworkRequest encapsulates the URL, and any header information to go with it.
QNetworkReply gives you the data stream from the server, and access to parsed headers that were received.

> With further analysis between the similarities of
> QIODevice/QAbstractSocket, I've changed my mind and now think that
> QAbstractDataChannel (as a replacement to QAbstractSocket) is a crappy
> base name. It's too ambiguous with QIODevice. So how about
> QAbstractConnectionStream instead to replace QAbstractSocket?

QUdpSocket isn't a stream, so it wouldn't be a clean replacement.

> Without providing concrete examples, changing the design to specify the
> connect parameters in the constructor provides an obvious benefit with
> zero cost. The old empty constructor remains, and so does the
> overloaded/helper connectTo with all the argument still there. This
> wouldn't even break the API if we didn't change the name (but we
> should).

To be clear, you mean the same pattern as QFile?
e.g.
QTcpSocket socket("www.qt-project.org", 80);
socket.connect();

connect() is a problematic name because it hides QObject::connect()

> If you require concrete examples, think of any case that justifies the
> existence of the current QAbstractSocket. Why was it created? Why
> weren't QTcpSocket and QUdpSocket just derived straight from QIODevice?
> Your answer to that is the answer to 'provide concrete examples of why
> QLocalSocket should derive from QAbstractSocket instead of QIODevice'.
> It should also seem like common sense seeing as QLocalSocket has the
> word "socket" in it.

I think most of the issues can be solved by connecting the socket first, then
using QIODevice as your base class pointer. When you call QIODevice::close() that
will disconnect the socket.

I'd like to see non blocking (or asynchronous) IO for files as well.

> All this chit-chat is worthless, but we should probably agree on a new
> base name at the very least. As for doing the same to QProcess's
> constructor: why not? Obvious gains, zero cost. QFile already has the
> filename optionally specifiable in the constructor :-), though it lacks
> an open(filename) overload (trivial to add).

You can call setFileName(filename) and then open() as normal.
Extra overloads are fine though if they make sense, they are generally backward compatible.
As they're backward compatible, they can go in a minor release such as 5.1

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.

______________________________________________________________________________________

www.accenture.com