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

[Brian Knox]

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 <
jimenezrick at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150721/9d2650eb/attachment.htm>