Re: [zeromq-dev] Client/Server Socket Prospects?

[Cunningham, Graeme]

8 16:51:15 +0200
From: Arnaud Loonstra 
To: zeromq-dev@lists.zeromq.org
Subject: Re: [zeromq-dev] Requiem for github
Message-ID: <4bb2271a-23f7-3149-9202-c8e5f4180...@sphaero.org>
Content-Type: text/plain; charset=utf-8; format=flowed

On 06/05/2018 10:32 PM, Benjamin Henrion wrote:
> I guess he would want us to move to Gitlab:
>
> http://hintjens.com/blog:111
>
> And leave a message for Microsoft on the dead Github...
>
> --
> Benjamin Henrion (zoobab)

It's really funny to see how relevant this still is. Indeed having a
beer during rants about this while we sit around and move everything to
gitlab...  :)

Arnaud.



--

Message: 4
Date: Wed, 6 Jun 2018 20:47:01 +
From: "Cunningham, Graeme" 
To: "zeromq-dev@lists.zeromq.org" 
Subject: [zeromq-dev] Client/Server Socket Prospects?
Message-ID:

Content-Type: text/plain; charset="utf-8"

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.?
------ next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180606/e15815d3/attachment-0001.html>

--

Message: 5
Date: Wed, 6 Jun 2018 17:02:56 -0400
From: Bill Torpey 
To: ZeroMQ development list 
Subject: Re: [zeromq-dev] Client/Server Socket Prospects?
Message-ID: 
Content-Type: text/plain; charset="utf-8"

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  
> 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

Re: [zeromq-dev] Client/Server Socket Prospects?

[Luca Boccassi]

On Wed, 2018-06-06 at 20:47 +, Cunningham, Graeme 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.

When it's ready (TM)

Note that the docs have been updated, and the current socket types are
un-deprecated as many users expressed the need to keep them (for
multipart support)

-- 
Kind regards,
Luca Boccassi

signature.asc
Description: This is a digitally signed message part
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Client/Server Socket Prospects?

[Bill Torpey]

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 
.  

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  
> 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 
> 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