Skip to content

Doesn't Rule 3.13 contradict 1.10? #334

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
schauder opened this issue Sep 17, 2016 · 5 comments
Closed

Doesn't Rule 3.13 contradict 1.10? #334

schauder opened this issue Sep 17, 2016 · 5 comments
Assignees
Milestone

Comments

@schauder
Copy link

3.13 says:

Re-subscribing with the same Subscriber object is discouraged [see 2.12], but this specification does not mandate that it is disallowed since that would mean having to store previously cancelled subscriptions indefinitely.

1.10 says:

Publisher.subscribe MAY be called as many times as wanted but MUST be with a different Subscriber each time

wouldn't the discouraged part of 3.13 result in a violation of 1.10 and thereby it is not just discouraged, but actually disallowed?

Or missing something?

@rkuhn
Copy link
Member

rkuhn commented Sep 17, 2016

1.10 defines permissible behavior of callers of subscribe, i.e. whoever calls that method must make sure to use a fresh Subscriber every time.

3.13 mandates that the Publisher drops all references to a Subscriber after the associated Subscription has been cancelled, meaning that the Publisher cannot be held responsible for enforcing that 1.10 is obeyed.

Hence, there is no contradiction, it is just that different parties are held accountable for different parts of the contract.

@schauder
Copy link
Author

Thanks, that makes sense. Would be great to have this kind of stuff in some comments to the rules. But I think there is already an issue for that, right?

@viktorklang
Copy link
Contributor

Yeah, I should get to that at some point. :S
I should try to set aside a week for that. If possible.

@viktorklang
Copy link
Contributor

Perhaps start an FAQ in the mean time?
Could someone try to do that?

@viktorklang
Copy link
Contributor

AFAIK solved by #339

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants