Initial implementation #1
Conversation
| @@ -0,0 +1,119 @@ | |||
| Reactive-Streams SPI Specification | |||
There was a problem hiding this comment.
Shouldn't this file be spec.md?
|
|
||
| ### Publisher::subscribe(Subscriber) | ||
|
|
||
| * when Publisher is in `completed` state |
There was a problem hiding this comment.
Why would a Publisher be in a completed state when subscribe is invoked?
Is this assuming Publisher is "hot", as in a Subject? On a "cold" Publisher a subscribe should just do the work each time it is subscribed.
Same goes for the error state.
There was a problem hiding this comment.
I guess implementation can adjust the buffering part when supplying a Publisher (which I would rather read Observable).
There was a problem hiding this comment.
We need to clarify if a Publisher is intended to multicast or not. It would be easier if we separate out like Observable and Subject as they have different characteristics and purposes.
There was a problem hiding this comment.
A Publisher may run out of elements, in which case it is “completed”. This is true for example for a TCP stream. A Publisher which just publishes the elements of a strict collection could indeed be implemented such that it reruns for every new Subscriber; it could also realized by creating a PublisherFactory which basically produces wrapped iterators for every new Subscriber. That area is currently not covered by this proposal, but we should of course make sure that the rules here support all use-cases we want to allow.
|
Roland, George and I spoke over Skype to clarify the scope of this ... it is narrower than I interpreted so many of my questions are invalidated. George and I are writing code with our various use cases to try out this proposal and see how it fits and if there are any tweaks we need or would like to propose. We'll respond with more in the next several days. |
|
Thanks, Ben! Looking forward to your feedback. We’ll draft a README to be added to this PR which summarizes what we talked about, to save others the same trouble. |
|
|
||
| **The API** specifies the types that the users of Reactive Stream libraries use. | ||
|
|
||
| ***The Technology Compatibility Kit (TCK)*** is astandard test suite for conformance testing of implementations. |
cancelled being true here is impossible because the only way to get that true is by submitting a Subscription to the Subscriber that happens once and under this condition.
This includes a first working prototype of the SPI, API and TCK. It is
meant to serve as a basis for more detailed discussion.
Most coding was done by Mathias Doenitz (@sirthias) and Johannes Rudolph
(@jrudolph) for Typesafe.