-
Notifications
You must be signed in to change notification settings - Fork 534
Prepare for 0.4.0.M1 #61
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
Changes from 24 commits
8b4d958
af380eb
092302b
5bab96e
0d11049
cf09f74
98a06e5
1ae8ba0
ec7c3bd
b0671e5
e6999a4
0561b6c
c800041
29804c5
e500c91
bc2576c
0a90836
f18f8f1
1883f39
5b02393
6dcb7ff
eed3826
8ffc64d
5aba6f8
f709200
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -21,3 +21,4 @@ github name | Real Name, Email Address used for git commits, Company | |
rkuhn | Roland Kuhn, [email protected], Typesafe Inc. | ||
benjchristensen| Ben Christensen, [email protected], Netflix Inc. | ||
viktorklang | Viktor Klang, [email protected], Typesafe Inc. | ||
smaldini | Stephane Maldini, [email protected], Pivotal Software Inc. |
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,7 +19,7 @@ public interface Subscription { | |
* A {@link Publisher} can send less than is requested if the stream ends but | ||
* then must emit either {@link Subscriber#onError(Throwable)} or {@link Subscriber#onComplete()}. | ||
* | ||
* @param n | ||
* @param n the strictly positive number of elements to requests to the upstream {@link Publisher} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you think about support a negative number to give freedom to the publisher to firehose data as fast as it wants without limits? An example use case is when a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this a lot. I'v been thinking the same thing about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As you wish as long as we reach consensus, I thought we discussed that before and there were some arguments in favor of staying that way. I may not foresee everything but right now in Reactor it just forces us to loop Integer.MAX-VALUE requests for never ending consumers. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please let us clarify this in a separate discussion, this is an orthogonal issue. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Left unchanged for the next push. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Opening an issue to discuss this here: #62 |
||
*/ | ||
public void request(int n); | ||
|
||
|
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rkuhn @viktorklang is there going to be any issue into publishing the artifact this way ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that I’d know (example: JUnit).