[Development] Common base class for all socket types

[Corentin Jabot]

I agree with d3fault/oswald.

Adding some setters/properties for the connection parameters of
QLocalSocket/QAbstractSocket and a generic "connect" method would make
the api somehow more usable.
Maybe a connectToHost() method - connectToPeer may be a little less generic.

QLocalSocket and QAbstractSocket already have getters so it would also
make the api more consistent - and similar to the QFile api


We could also ensure that the open/close methods of
QLocalSocket/QAbstractSocket actually connect/disconnect it  (it is
currently the other way around)

so one could do
QLocalSocket socket("foo_pipe");  // or QTcpSocket("localhost", 42)
socket.open();
...
socket.close();

of course, QLocalSocket would still need to inherit from
QAbstractSocket  for methods suchs socketType(), error(), state() and
waitForConnected/Disconnected()

2012/11/8 Thiago Macieira <thiago.macieira at intel.com>:
> On quinta-feira, 8 de novembro de 2012 15.48.29, shane.kearns at accenture.com
> wrote:
>> 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.
>
> QNAM proves that it is possible. The put() and post() methods taking a
> QIODevice pointer operate on any class deriving from QIODevice. The
> QNetworkReply test tests QFile, QBuffer, QTcpSocket, QSslSocket, QProcess and
> QNetworkReply itself.
>
> The only thing is that it requires two implementations: the random-access one
> (QFile, QBuffer) and the sequential one (all the rest).
>
>> I'd like to see non blocking (or asynchronous) IO for files as well.
>
> Would be interesting.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>