-
Notifications
You must be signed in to change notification settings - Fork 534
compact 1.14–17 #65
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
Comments
Merged
Do everyone agree here? @reactive-streams/contributors |
👍 |
1 similar comment
👍 |
👍 |
👍 |
👍 |
It may be useful to introduce state diagrams. |
@mariusaeriksen It makes sense to have an appendix section with guidelines for stateful Publishers. |
Time to finalize the votes, if you need more time, please respond here with how much time (reasonable) is needed to cast your vote. @reactive-streams/contributors |
👍 |
viktorklang
added a commit
that referenced
this issue
Jul 9, 2014
viktorklang
added a commit
that referenced
this issue
Jul 9, 2014
viktorklang
added a commit
that referenced
this issue
Jul 9, 2014
Fixes #65 - Removes 1.15, 1.16 and 1.17 since they are covered by 1.14
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
discussion was:
@rkuhn on 1.14
Please move the parenthesis out into a footnote and add more cases in which Subscribers may be rejected: when the Publisher cannot produce any more elements (exhausted a non-restartable source, shut down its resources; in general covering the cases from rules 15–17).
@benjchristensen on 1.15
How is a publisher in a "completed" state? A Subscription may be (it has already emitted a terminal event) and a Subscriber definitely can be, but a Publisher doesn't have such a state.
I suggest removing this point and just leaving 1.14 to cover this as a Publisher can onError if it wants to, but that has nothing to do with being in a "completed" state.
@viktorklang
A hot publisher can most definitely be in a completed state?
@benjchristensen
Then it would just onError when someone tries to subscribe. Nothing about the Publisher requires formalized states.
Item 1.14 covers everything that is needed for the use case you give. It is confusing to consider Publisher states when we support both hot and cold implementations.
@smaldini
I think the behavior stays covered in 1.14 as highlighted, Maybe we could move this into a note for reference "Stateful Publisher".
@benjchristensen
I'm fine with a "Stateful Publisher" section of notes if that is helpful.
@rkuhn
Agree with @benjchristensen here: the reasons why a Publisher wants to not be woken up again can be manifold, we don’t need to express one rule for each of them. My proposed solution is to remove 15–17 and move them into the footnote suggested for 14 above.
The text was updated successfully, but these errors were encountered: