Skip to content
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

2.x: Reactive-Streams compliance #5110

Closed
akarnokd opened this issue Feb 17, 2017 · 3 comments
Closed

2.x: Reactive-Streams compliance #5110

akarnokd opened this issue Feb 17, 2017 · 3 comments
Milestone

Comments

@akarnokd
Copy link
Member

There is an ongoing effort to clarify the reasons behind the Reactive-Streams rules. In the hopes that the rules could be relaxed without too much compatibility problems, I brought up the case that we had to introduce the strict() operator to pass the TCK tests. The problematic rules are §1.3 and §3.9 that impose such requirements that add overhead to sequences.

This sparked a separate discussion about the it was a good idea RxJava 2 exposes itself with the Reactive-Streams interfaces instead of hiding it behind a converter / exposure layer which decoupling allows - in theory - violating the exact rules as long as such violations are not visible by the consumer.

I doubt I could convince the maintainers of the specification (other than @smaldini) it is worth taking the relaxations even at the expense of temporary incompatibility in case vendor's don't relax their particular implementations.

RxJava 2 works with or without the "Reactive-Streams compliant" badge yet as a "brand", it is still advisable to have that badge.

Suggested API changes

Ensuring conformance is a matter of applying the StrictSubscriber wrapper to the incoming Subscriber in Flowable.subscribe. Unfortunately, this slows down everything as there is only one way to consume a Flowable through subscribe(Subscriber) (the overloads all delegate to it).

To get the speed back, a new instance method would be introduced that all internal operators would use then on instead of subscribe. RxJava 1 has an extra entry point unsafeSubscribe to sidestep SafeSubscriber thus there is precedence for such alternate entry point.

The method could be called subscribe as well that takes a FlowableSubscriber extends Subscriber. FlowableSubscribers textual definition can then weaken rules §1.3 and §3.9 inherited. Existing operators would then implement FlowableSubscriber in place of Subscriber.

I think all of this would be binary compatible change since only Flowable would get an extra method.

Suggestions welcome.

@akarnokd akarnokd added this to the 2.1 milestone Feb 17, 2017
@JakeWharton
Copy link
Contributor

Is FlowableSubscriber a public type just like the non-RS observers?

I've been following the discussion too and I think this is a reasonable action to take.

@akarnokd
Copy link
Member Author

Yes, io.reactivex.FlowableSubscriber. I don't think hiding it in internal is necessary. I'm currently preparing a PR to demonstrate the changes.

@akarnokd
Copy link
Member Author

Closing via #5112.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants