Skip to content

2.x Design: Subject #3349

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Sep 21, 2015
Merged

2.x Design: Subject #3349

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions DESIGN.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,9 +66,18 @@ Consumer of events without flow control.

##### Subject

A "hot" data source that allows a producer to emit events and consumers to receive events in a multicast manner.
A "hot", push-based data source that allows a producer to emit events to it and consumers to subscribe to events in a multicast manner. It is "hot" because consumers subscribing to it does not cause side-effects, or affect the data flow in any way. It is push-based and reactive because the producer is fully in charge.

It is "hot" because consumers subscribing to it does not cause side-effects, or affect the data flow in any way. It is push and reactive because the producer is fully in charge.
Relation to Reactive Streams

- It can not implement Reactive Streams `Publisher` unless it is created with a default flow control strategy.
- It can not implement `Processor` since a `Processor` must compose `request(n)` which can not be done with multicasting or pure push.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've read the spec but I haven't seen an implication of this. The only rule I can deduce is that Processor may not overflow its subscribers. Nothing about request coordination requirement. This is what publish() is for.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4.1: A Processor represents a processing stage—which is both a Subscriber and a Publisher and MUST obey the contracts of both.

Thus, it has to obey the rules of a Publisher which can't overflow its subscribers as per rule 1.1:

1.1 The total number of onNext signals sent by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.

I strongly argued against Processor as it looks like a Subject but can't be used as one. It is actually more like the RxJava Operator, but requires subscription rather than lifting into the observer chain.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is exactly why we stopped using Subjects inside RxJava v1 Observable operators, such as publish(), and why we removed multicast(Subject s).

A Subject can not compose request(n). That's why v1 Observable.publish() behaves very differently than a PublishSubject and will slow down to the slowest consumer.


Flow control support:

- buffering, sampling, throttling, windowing, dropping, etc
- temporal and count-based strategies
- It does not support pull-based consumer-driven flow control.

##### Disposable

Expand Down