OnSubscribe vs return Subscription

[benjchristensen]

The mechanism for receiving a Subscription is worth discussion as there are differing views on this.

Currently it is passed back from the Publisher to the Subscriber:

public interface Publisher<T> {
    public void subscribe(Subscriber<T> s);
}

public interface Subscriber<T> {
    public void onSubscribe(Subscription s);
}

It could however be like this:

public interface Publisher<T> {
    public Subscription subscribe(Subscriber<T> s);
}

Or as shown here it could be:

public interface Publisher<T> {
    public Subscription<T> subscribe();
} 

public interface Subscription <T> {
    public void request(Subscriber<T> reader, int n);
    public void close();
}

[jbrisbin]

Who cares more about having access to the Subscription? The caller of subscribe or the Subscription itself?

It seems the last version of request(Subscriber, int) would be very flexible but would violate any one-subscriber-one-subscription rule.

[viktorklang]

I agree with @jbrisbin.
The current solution was deliberately chosen to keep the Subscription between the Publisher and the Subscriber. Since only the Subscriber is allowed to call methods on the Subscription I'd argue that the current solution is the cleanest, smallest and most correct since it eliminates checking for a lot of invariants.

What are the pros/cons for the proposed alternative solutions?

[smaldini]

I guess the point is where the Publisher is representing a cold source vs a hot source. Since the state is held by the Subscription, there will be a need to expose it to fill its buffer from the upstream perspective meaning that the publisher can also interact with the subscription.

[viktorklang]

Since the Publisher creates the Subscription internally (in subscribe) it
already has a ref to the subscription, and that's the same no matter hot or
cold?
On Apr 25, 2014 10:13 AM, "Stephane Maldini" [email protected]
wrote:

I guess the point is where the Publisher is representing a cold source vs
a hot source. Since the state is held by the Subscription, there will be a
need to expose it to fill its a buffer from the upstream perspective
meaning that the publisher can also interact with the subscription, not
only the subscriber.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/43#issuecomment-41368869
.

[smaldini]

Sure, my point is I would rearrange the sentence to not limit the Subscriber only to have access to this Subscription. The publisher whether it holds a list of them or just register a new event loop/actor etc will certainly need to interact with the Subscription.

[rkuhn]

The only parties involved in the usage of a Subscription are the Publisher and the Subscriber, no party outside of this very select group should by default have any interest in it. Sure, you can implement both such that they expose the Subscription to outsiders, but that would be useful only for purposes not covered by the spec.

The other reason for not returning the Subscription—in fact the reason for returning void from all specified methods—is that it should be possible to implement the spec with an execution model that is entirely asynchronous. Returning a strict value would break that property.

[benjchristensen]

it should be possible to implement the spec with an execution model that is entirely asynchronous

I think this is the most concrete reason for why onSubscribe needs to exist as a callback. In Rx it could be done either way, but I imagine in Akka (or any actor implementation) it needs to always be done as a callback.

Thus, I think we need to support purely async implementations and retain the void subscribe/void onSubscribe signature.

[benjchristensen]

What are the pros/cons for the proposed alternative solutions?

The pro for public Subscription subscribe(Subscriber<T> s) is that it removes a callback for a simpler interface and eliminates at least one step in the subscription process. The negative is it makes async implementations very awkward as the Publisher would have to immediately return a Subscription that may not actually be fulfilled yet until the remote asynchronously responds. Thus, the void subscribe/void onSubscribe is more flexible to all possible implementations.

The void request(Subscriber<T> reader, int n) alternative was suggested by @mariusaeriksen so he'll need to get involved on that one.

[rkuhn]

Summing it up: we seem to agree on keeping the current interface definition, but we should add clarification that for the purposes of this specification a Subscription is shared by exactly one Publisher–Subscriber pair (i.e. both have access, and none other needs access for the scope of Reactive Streams alone). Together with the goal of specifying a completely asynchronous exchange this would then also be the documented rationale behind having void subscribe(Subscriber) and void onSubscribe(Subscription). I volunteer to perform any necessary documentation changes once this has enough votes.

[jbrisbin]

I'm in favor of keeping void return types.

[benjchristensen]

we seem to agree on keeping the current interface definition

I agree with keeping the current ones that return void.

for the purposes of this specification a Subscription is shared by exactly one Publisher–Subscriber pair

Agreed.

[smaldini]

+1

[mariusae]

+1

[viktorklang]

Sounds like the sweet sound of consensus to me. Moving to close.