[Development] Common base class for all socket types

[d3fault]

On 11/8/12, Corentin Jabot <corentin.jabot at gmail.com> wrote:
> so one could do
> QLocalSocket socket("foo_pipe");  // or QTcpSocket("localhost", 42)
> socket.open();
> ...
> socket.close();
>

I agree that the actual connectToHost() impl should live in open() so
we can control it additionally using a QList<QIODevice*>, but I think
we should keep connectToHost() around to keep the API intuitive. It
will seem confusing from a _user_ perspective to call open() and then
waitForConnected(). Same with
disconnectFromHost/close/waitForDisconnected.


Extra reading:
QIODevice vs. QAbstractSocket
A QIODevice is generally only alive/active in between the calls to
open/close (there are exceptions)... and typically only allows one
'client' to IO to the device or else you'll [possibly/probably] face
syncrhonization issues. Constrast this with QAbstractSocket, where the
'service' is alive before and after calls to open/close
(connect/disconnect)... and it can/does handle multiple 'clients'
regularly. Again, to restate: you CAN communicate with a 'server'
(usually referred to as a daemon when used like this) through a
process/file (iodevices), but this is generally not the case.

Making QLocalSocket inherit from QAbstractSocket gives the _user_ a
simple and intuitive way to have a server that can communicate with
local peers (different thread (different process on same machine) and
remote peers (LAN, WAN) using the same client/server implementation.
The clients and servers don't need to care where their peers live. The
current design (making you utilize QIODevice as the base class) means
the client implementation has to know what kind of socket it is
communicating over (glue code, see:
http://lists.qt-project.org/pipermail/development/2012-November/007769.html
), you cannot simply call open() (or connectToHost()) and not worry
about it. Separation of concerns.

Current QIODevice base: "client" impl can't cleanly/easily
connect/disconnect at will (it has to know the sub type)
Revised QAbstractDevice base: "client" impl can't cleanly/easily
INSTANTIATE (done once) at will, but CAN connect/disconnect (as many
times as he wants) at will without knowing the socket type


Pretty sure my subconscious came up with all this while I was sleeping,
d3fault