change “MUST reject” to RECOMMENDED in 1.12

[rkuhn]

discussion was:

@benjchristensen

Why is this up to the Publisher to enforce this? That requires bookkeeping in an aggregated data structure whereas normally a unicast Publisher/Subscription will only ever know about the single Subscriber it is currently associated with. The Publisher shouldn't have to track every Subscriber it ever saw and then deal with the cleanup. This adds concurrency and memory overhead.

I would change "It MUST reject the Subscription" to "It MAY reject the Subscription" and have something under the Subscriber in section 2 that states that it can't subscribe more than once with a single Subscriber instance.

Updated ... section 2.5 already addresses this requirement.

@viktorklang

I'm not sure I understand your concern, there needs to be a link between publisher and subscriber anyway, via the subscription?

@benjchristensen

No there isn't. There is a link between the Subscriber and Subscription. There is no requirement for the Publisher to maintain any reference at all to either of those instances after the Publisher.subscribe call.

This simple example demonstrates how the Publisher is just a factory and never retains a reference to the Subscriber or Subscription: https://github.com/reactive-streams/reactive-streams/blob/master/api/src/examples/java/org/reactivestreams/example/unicast/InfiniteIncrementNumberPublisher.java
This requirement would force the Publisher to maintain a data structure with references to every Subscriber that has not yet unsubscribed. That is unnecessary overhead and complexity.

@rkuhn

While there certainly are Publishers with the characteristics you describe, this is not in general true: most “hot” sources will have knowledge of whom to produce to in a central place already.

That being said, your point is valid that requiring this behavior of all Publishers is too limiting. What about changing the MUST into a RECOMMENDED, meaning that the Publisher should inform the caller of subscribe that they are doing something wrong if possible; we are regulating a spec violation in any case.

[benjchristensen]

Link to original discussion: #61 (comment)

[viktorklang]

RECOMMENDED sounds good to me, makes the responsibility of double-subscription shared between publishers and subscribers.

[viktorklang]

Others? @reactive-streams/contributors

[smaldini]

👍

[viktorklang]

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

[benjchristensen]

👍

[tmontgomery]

👍