Good point Brian. Yeah, I see that all the existing flags controlling the behavior of ZMQ are boolean. In that case I'll add a new flag, something like:
ZMQ_XPUB_VERBOSE_UNSUBSCRIBE Sounds good, I'll submit soon a PR and let continue the discussion in there. Thanks Brian, On Tue, Jul 21, 2015 at 09:32:01AM -0400, Brian Knox wrote: > 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 < > [email protected]> 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 < > > > [email protected]> 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 > > > > [email protected] > > > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > > > /Ricardo > > /Ricardo _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
