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

Reply via email to