Aha! In that case, I think adding the extra flag is the right choice. An additive change is better than a breaking change. I agree that off the top of my head I'm not sure what this behavior is leveraged for, but that certainly doesn't mean it's not being used in a way that's useful to someone.
Cheers, Brian On Tue, Jul 21, 2015 at 8:13 AM, Ricardo Catalinas Jiménez < [email protected]> wrote: > 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." > > Well, unfortunately it's documented, so any change on this would break > the contract fo the current API. Although I don't find much value in > this behavior because it just add complexity, this is what the current > doc says: > > ZMQ_UNSUBSCRIBE: > > "If the socket has several instances of the same filter attached the > ZMQ_UNSUBSCRIBE option shall remove only one instance, leaving the rest > in place and functional." > > Which implicitly is referring to the reference counting happening > underneath. So, unless someone with authority says we should modify > this, I guess it's something we shouldn't touch. > > > 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. > > /Ricardo >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
