Clarify `multi-subscribe` in 1.11

[viktorklang]

Can be confusing (does it mean multiple calls to subscribeor multiple Subscribers) (it's the latter)

[szeiger]

It is still unclear to me what unicast and multicast mean in this context, especially in the light of 1.12 which explicits prohibits sending different elements to different subscribers.

[viktorklang]

Unicast would be for instance a Publisher of a known sequence where every Subscriber would be able to consume that in their own speed.

Multicast would be to not knowing all elements up front and then publishing the elements as they arrive to all its subscribers.

Does that make more sense?

[szeiger]

What happens in the multicast case if one subscriber can keep up with the stream and another cannot? May the publisher drop messages to the slow subscriber and still send them to the fast one? This seems to be forbidden by 1.12.

[viktorklang]

@szeiger either you rate limit to the slowest subscriber or you onError it for not keeping up.

[szeiger]

So no unicast for hot streams allowed?

[viktorklang]

@szeiger You mean like a Publisher of random numbers where every subscriber gets their own sequence? No, I think 1.12 would prohibit that.

A Publisher MUST produce the same elements, starting with the oldest element still available, in the same sequence for all its subscribers and MAY produce the stream elements at (temporarily) differing rates to different subscribers.

One could toy with the definition of still available though.