In the current api we have a method
Flowables::fromPublisher(OnSubscribe);OnSubscribe = std::function<void(Subscriber)>;
In the body of the OnSubscribe lambda the user is required to call subscriber->onSubscribe(subscription) before calling any on{Next, Complete, Error}.
Problem:
In many cases the users are using this API to bridge from a standard callback api to flowables and they do it typically wrong.
Common user mistakes:
not calling onSubscribe first
the subscription passed into onSubscribe is receiving request(n) calls but the credits are often ignored.
The api is requiring the user to know the protocol intimately and not mess up credits. Its very bug prone.
Proposal
If we remove Flowables::fromPublisher, we will force the users to use Observables::create method which doesn't require onSubscribe to be called, nor it has flow control.
The fromPublisher method seems quite useful in the cases we are connecting a Subscriber instance to a different Flowable.
Maybe we can just rename fromPublisher to unsafeSubscriberGetter which would just discourage users to use it.
In the current api we have a method
Flowables::fromPublisher(OnSubscribe);OnSubscribe = std::function<void(Subscriber)>;In the body of the OnSubscribe lambda the user is required to call
subscriber->onSubscribe(subscription)before calling anyon{Next, Complete, Error}.Problem: In many cases the users are using this API to bridge from a standard callback api to flowables and they do it typically wrong.
Common user mistakes:
The api is requiring the user to know the protocol intimately and not mess up credits. Its very bug prone.
Proposal If we remove Flowables::fromPublisher, we will force the users to use Observables::create method which doesn't require onSubscribe to be called, nor it has flow control.
The fromPublisher method seems quite useful in the cases we are connecting a Subscriber instance to a different Flowable.
Maybe we can just rename fromPublisher to unsafeSubscriberGetter which would just discourage users to use it.