Thanks Bill, Luca for your inputs. Graeme Cunningham.
-----Original Message----- From: zeromq-dev [mailto:[email protected]] On Behalf Of [email protected] Sent: Thursday, June 07, 2018 4:00 AM To: [email protected] Subject: zeromq-dev Digest, Vol 27, Issue 6 Send zeromq-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.zeromq.org/mailman/listinfo/zeromq-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of zeromq-dev digest..." Today's Topics: 1. Re: Requiem for github (Michael Powell) 2. Re: Requiem for github (Greg Young) 3. Re: Requiem for github (Arnaud Loonstra) 4. Client/Server Socket Prospects? (Cunningham, Graeme) 5. Re: Client/Server Socket Prospects? (Bill Torpey) 6. Re: Client/Server Socket Prospects? (Luca Boccassi) ---------------------------------------------------------------------- Message: 1 Date: Wed, 6 Jun 2018 10:07:23 -0400 From: Michael Powell <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] Requiem for github Message-ID: <CAMEoF_HJonEiE_fj8w=i7eerst-62g0fwte0zvetwxazjgc...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" On Tue, Jun 5, 2018 at 4:32 PM, Benjamin Henrion <[email protected]> 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... Is there something you know that the rest of us do not? I am just now catching wind of the apparently coming acquisition of GitHub by Microsoft. > -- > Benjamin Henrion (zoobab) > Email: zoobab at gmail.com > Mobile: +32-484-566109 > Web: http://www.zoobab.com > FFII.org Brussels > "In July 2005, after several failed attempts to legalise software > patents in Europe, the patent establishment changed its strategy. > Instead of explicitly seeking to sanction the patentability of > software, they are now seeking to create a central European patent > court, which would establish and enforce patentability rules in their > favor, without any possibility of correction by competing courts or > democratically elected legislators." > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------------------ Message: 2 Date: Wed, 6 Jun 2018 21:26:00 +0700 From: Greg Young <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] Requiem for github Message-ID: <CAC9RQtgrYy-eeYz_dD0kYu98qXessc2LC6u5nQ+LnwHGVr=-9...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I will second the original posters viewpoint (but I'm uninvolved this is more just a Pieter reflection). I can only imagine sitting with Pieter today and listening to him rant about github and the acquisition (especially given recent news) :P To be fair it would be the best beer I have had in a long time :) On Wed, Jun 6, 2018 at 9:07 PM Michael Powell <[email protected]> wrote: > On Tue, Jun 5, 2018 at 4:32 PM, Benjamin Henrion <[email protected]> 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... > > Is there something you know that the rest of us do not? I am just now > catching wind of the apparently coming acquisition of GitHub by > Microsoft. > > > -- > > Benjamin Henrion (zoobab) > > Email: zoobab at gmail.com > > Mobile: +32-484-566109 > > Web: http://www.zoobab.com > > FFII.org Brussels > > "In July 2005, after several failed attempts to legalise software > > patents in Europe, the patent establishment changed its strategy. > > Instead of explicitly seeking to sanction the patentability of > > software, they are now seeking to create a central European patent > > court, which would establish and enforce patentability rules in their > > favor, without any possibility of correction by competing courts or > > democratically elected legislators." > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > -- Studying for the Turing test -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180606/f98b111e/attachment-0001.html> ------------------------------ Message: 3 Date: Wed, 6 Jun 2018 16:51:15 +0200 From: Arnaud Loonstra <[email protected]> To: [email protected] Subject: Re: [zeromq-dev] Requiem for github Message-ID: <[email protected]> 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 +0000 From: "Cunningham, Graeme" <[email protected]> To: "[email protected]" <[email protected]> Subject: [zeromq-dev] Client/Server Socket Prospects? Message-ID: <[email protected]> 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] Client/Server Socket Prospects? Message-ID: <[email protected]> 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 <[email protected]> > 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 > [email protected] <mailto:[email protected]> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > <https://lists.zeromq.org/mailman/listinfo/zeromq-dev> -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180606/da656360/attachment-0001.html> ------------------------------ Message: 6 Date: Wed, 06 Jun 2018 22:41:29 +0100 From: Luca Boccassi <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] Client/Server Socket Prospects? Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" On Wed, 2018-06-06 at 20:47 +0000, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180606/a3e4ad10/attachment-0001.sig> ------------------------------ Subject: Digest Footer _______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------------------ End of zeromq-dev Digest, Vol 27, Issue 6 ***************************************** “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 [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
