Description
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.
A hot publisher can most definitely be in a completed state?
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.
I think the behavior stays covered in 1.14 as highlighted, Maybe we could move this into a note for reference "Stateful Publisher".
I'm fine with a "Stateful Publisher" section of notes if that is helpful.
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.