I’m interested in that as well — when I asked this question last year I got the following reply from Luca: https://lists.zeromq.org/pipermail/zeromq-dev/2017-October/031960.html <https://lists.zeromq.org/pipermail/zeromq-dev/2017-October/031960.html>.
My take on it is that client/server will be supported, although there might be (breaking) API changes at some point. It sounds like the breaking API changes might have to do with having the thread-safe socket types support multi-part messages, which they do not today. If that has changed I’d love to know myself, since I’m relying on CLIENT/SERVER sockets to provide IPC. I could use PUSH/PULL also, but CLIENT/SERVER is simpler because they are thread-safe. > On Jun 6, 2018, at 4:47 PM, Cunningham, Graeme <graeme.cunning...@gd-ms.ca> > wrote: > > Can somebody on this list give an indication as to how likely the > Client/Server pattern (RFC41) is to be supported and promoted to “stable” in > the future? > > We’re building a number of interfaces on ZeroMQ in our new project, but we’re > wavering a bit on pattern design, given some of the statements in the API > around Client/Server and the socket patterns it’s intended to replace. We > are aware that the Client/Server is labelled as draft, but there are still > some notable statements in the API document about REQ/RESP being deprecated. > > Is there a strong intention to continue pushing Client/Server to the stable > API? Should we be pushing that pattern into new designs over the older > socket types? > > I realize such a decision ultimately depends on our own appetite for risk > tolerance, but any insight would be appreciated. > > Thanks, > Graeme Cunningham. > > “This message and/or attachments may include information subject to GD > Corporate Policies 07-103 and 07-105 and is intended to be accessed only by > authorized recipients. Use, storage and transmission are governed by General > Dynamics and its policies. Contractual restrictions apply to third parties. > Recipients should refer to the policies or contract to determine proper > handling. Unauthorized review, use, disclosure or distribution is prohibited. > If you are not an intended recipient, please contact the sender and destroy > all copies of the original message.” > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev>
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev