[zeromq-dev] Not receiving unsubscription messages in XPUB socket with ZMQ_XPUB_VERBOSE when using a proxy

[Brian Knox]

Do we have any other cases where a flag accepts more than one value?  As
far as I know, we don't, and in that case it would be my preference to use
a new flag than to have "modes" for a flag other than on and off.  I
certainly don't speak for everyone though, and according to our own
development method I shouldn't be a gate keeper if your PR solves a problem
unless your PR breaks compatibility / tests or doesn't follow the style
guidelines.

Sometimes the best way to find out what opinions are out there is to submit
the PR, which will either generate discussion or be accepted - after which
if people have issue with the implementation, they'll submit a follow up PR.

Cheers,
Brian

On Tue, Jul 21, 2015 at 9:11 AM, Ricardo Catalinas Jiménez <
jimenezrick at gmail.com> wrote:

> OK, this is my definitive proposed solution, which is a bit simpler and
> should keep everyone happy. If nobody sees an obstacle here, I'll
> prepare soon a pull request with this changes:
>
> 1. As I described before, don't filter repeated unsubscribe messages in
>    XSUB. This shouldn't break any API contract.
>
> 2. Instead of adding a new flag, add a new accepted value by the already
>    existing ZMQ_XPUB_VERBOSE, so from now on, apart from accepting 0 and
>    1, this flag will also accept 2, making unsubscribe messages algo
>    verbose (no filtering). This is a small incremental change to the API
>    that doesn't break anything. This new value should be used always in
>    proxies and optionally it can be use in applications that want this
>    behavior.
>
> Hope this sounds more sensible.
>
> On Tue, Jul 21, 2015 at 08:02:54AM -0400, Brian Knox wrote:
> > Ricardo - if you are lucky, there might be a loophole here for you to
> > exploit with a little lawyering.
> >
> > "This is my preferred solution although it could break applications
> > that subscribe multiple times to the same topic and expect to stop
> > receiving messages only when they unsubscribe the same number of
> > times.  Although I'm not aware that this behavior is documented
> > which could mean it isn't really a problem."
> >
> > Do you know if there is a specific test case for this behavior?  If your
> > change changes this behavior but does not break the test suite, I believe
> > it might be accepted.  One of the guiding principals for ZeroMQ
> development
> > is, paraphrased, "if you liked it should have put a test around it".  "A
> > breaking change" is usually interpreted to mean "it breaks the tests"
> (note
> > it's the wording Pieter used in his response).  If this behavior is not
> > documented and it is not tested you should be in good shape, as far as I
> > know.
> >
> > Cheers,
> > Brian
> >
> >
> > On Tue, Jul 21, 2015 at 6:47 AM, Ricardo Catalinas Jiménez <
> > jimenezrick at gmail.com> wrote:
> >
> > > Correction, I meant XSUB in point 1.
> > >
> > > On Tue, Jul 21, 2015 at 11:36:28AM +0100, Ricardo Catalinas Jiménez
> wrote:
> > > > [...]
> > > >
> > > > 1. Don't filter repeated unsubscribe messages in *XSUB*...
> > > >
> > > > [...]
> > >
> > >
> > > /Ricardo
> > > _______________________________________________
> > > zeromq-dev mailing list
> > > zeromq-dev at lists.zeromq.org
> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > >
>
>
> /Ricardo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150721/8ec84d71/attachment.htm>