On 11/8/12, Corentin Jabot <corentin.ja...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development