[Development] Common base class for all socket types

[Corentin Jabot]

The following changes enable the connection of qlocalsocket &
qabstractsocket by QIODevice::open(), making (a little) easier to mix
them.

https://codereview.qt-project.org/#change,39371
https://codereview.qt-project.org/#change,40592

The documentation certainly needs rework.

Hopefully, they will be integrated in 5.1.

They add setters for the parameters usually passed to
connectToSocket/Server methods.
But, I did not add properties. The reason is there is not properties
in other QIODevice subclass.
I'm not sure properties are needed, but, if we want add them, we
should also add some in QFile and other QIODevice in a consistent
manner.

I don't think much more can be done to ease the mix of different
sockets type before 6.0.



2012/11/9 d3fault <d3faultdotxbe at gmail.com>:
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development