{"action":"created","issue":{"url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/1","labels_url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/1/comments","events_url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/1/events","html_url":"https://github.com/reactive-streams/reactive-streams-io/issues/1","id":59112074,"number":1,"title":"Goals and Motivation","user":{"login":"benjchristensen","id":813492,"avatar_url":"https://avatars.githubusercontent.com/u/813492?v=3","gravatar_id":"","url":"https://api.github.com/users/benjchristensen","html_url":"https://github.com/benjchristensen","followers_url":"https://api.github.com/users/benjchristensen/followers","following_url":"https://api.github.com/users/benjchristensen/following{/other_user}","gists_url":"https://api.github.com/users/benjchristensen/gists{/gist_id}","starred_url":"https://api.github.com/users/benjchristensen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benjchristensen/subscriptions","organizations_url":"https://api.github.com/users/benjchristensen/orgs","repos_url":"https://api.github.com/users/benjchristensen/repos","events_url":"https://api.github.com/users/benjchristensen/events{/privacy}","received_events_url":"https://api.github.com/users/benjchristensen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":27,"created_at":"2015-02-26T18:00:47Z","updated_at":"2015-03-13T19:08:49Z","closed_at":null,"body":"Due to the successful collaborations on [Reactive Streams for the JVM](https://github.com/reactive-streams/reactive-streams-jvm) and community involvement in [Reactive Extensions (RxJava and friends)](https://github.com/ReactiveX/RxJava) I want to pursue greater [polyglot support](https://github.com/reactive-streams/reactive-streams-jvm/issues/45) of the Reactive Stream semantics. This includes both language specific interfaces and over-the-network protocols. I propose that we collaborate as a community to achieve the use cases I list below, along with any others I'm missing that we derive together. \r\n\r\nIn full disclosure, personally I am building systems that need polyglot, stream-oriented network interaction, primarily between Java and JavaScript in the near future. I prefer to collaborate and design the solution openly rather than reinvent yet another competing solution. I am unsatisfied with current solutions or unaware of better ones. Teams at Netflix are creating custom one-off solutions based on ReactiveX/Reactive-Stream semantics and I'd prefer we not do this in isolation. Selfishly I want the input of people far better at this domain than I am since I am out of my league in defining network protocols and interfaces in non-Java languages. I also want to avoid NIH (not-invented-here) and solve these problems across organizations and companies since systems I'm building will most likely outlive my involvement in them and community support and involvement in core, foundational networking and messaging layers is far better than home grown solutions in the long run. I expect this to slow me down in the near term, but greatly accelerate and improve the medium and long-term accomplishments, and significantly improve the final outcome. \r\n\r\nThe timelines I'm hoping for would be functioning prototypes and protocol drafts in a few months, with release candidates in 6-9 months (Q3/Q4-2015) and a GA release in early 2016. I and the team I work with at Netflix intend on building our systems along these timelines to be proving out what we design here. \r\n\r\nAdditionally, I hope for collaboration across expertise domains to allow for debate, critiques, ideas and solutions that would not occur while staying in our individual silos. \r\n\r\n## Use Cases\r\n\r\nThe intent is to enable Reactive Stream semantics for async, stream-oriented IO supporting backpressure and cancelation. \r\n\r\nOn top of protocols such as TCP, WebSockets and possibly HTTP/2 it would allow bi-directional, multiplexed communication for these semantics:\r\n\r\n* subscribe, request(n), cancel\r\n* onNext, onError, onComplete\r\n\r\nUsage patterns would include:\r\n\r\n#### Scalar Request, Scalar Response \r\n\r\nThis would behave similarly to RPC/IPC calls. \r\n\r\nFor example:\r\n\r\n* UP subscribe(\"hello\", 1) // to eliminate round-trip, the initial `request(n)` could be included in the subscribe\r\n* DOWN onNext(\"World!\")\r\n* DOWN onComplete\r\n\r\n#### Scalar Request, Vector Response \r\n\r\nThis would behave similarly to HTTP Server-Sent-Events.\r\n\r\nFor example:\r\n\r\n* UP subscribe(\"names\", 100) // to eliminate round-trip, the initial `request(n)` could be included in the subscribe\r\n* DOWN onNext(\"Dave\")\r\n* DOWN onNext(\"Tom\")\r\n* DOWN onNext(\"Sarah\")\r\n* DOWN onComplete\r\n\r\nOr with request(n) and unsubscribe on an infinite stream:\r\n\r\n* UP subscribe(\"increment\", 3) // to eliminate round-trip, the initial `request(n)` could be included in the subscribe\r\n* DOWN onNext(1)\r\n* DOWN onNext(2)\r\n* DOWN onNext(3)\r\n* UP request(2)\r\n* DOWN onNext(4)\r\n* DOWN onNext(5)\r\n* UP unsubscribe\r\n\r\n#### Bidirectional Streams \r\n\r\nThis would behave more like raw TCP or WebSockets. \r\n\r\nThe following example is very poor, but representative of desire for messaging UP with event propagation DOWN across multiple subscriptions.\r\n\r\n* UP subscribe(\"user-events-XYZ\", 100)\r\n* UP subscribe(\"data-updates\", 100)\r\n* UP msg(\"eventA\", \"abc\") // fire-and-forget a message\r\n* DOWN onNext(\"user-events-XYZ: eventA Completed\")\r\n* UP msg(\"/do/something\", \"args\")\r\n* DOWN onNext(\"user-events-XYZ: x-updated\")\r\n* DOWN onNext(\"data-event: 8756-modified\")\r\n\r\n\r\n\r\n## Possible Outcomes\r\n\r\nIntended outcomes of this pursuit are:\r\n\r\n1) Discover there is already a solution for this and we can shut this down and use it.\r\n2) Decide we can't agree and we go off and build our own custom things.\r\n3) We determine this is a useful and newish thing, collaborate and build the above. \r\n\r\n\r\n## Artifacts\r\n\r\nFollowing are artifacts envisioned from this collaboration during this first phase.\r\n\r\n#### Network Protocol\r\n\r\nThis is expected as purely a network protocol. Due to my ignorance I can't specify more, but I expect variations for:\r\n\r\n- binary and text (for example, into JavaScript apps it may be valuable to support text/JSON whereas interprocess Java/C/Go/etc would benefit from binary)\r\n- unidirectional and bidirectional transport layers (TCP vs HTTP/1 vs WebSockets vs HTTP/2 etc as tranport layers)\r\n- how serialiation and protocol negotiation should work\r\n\r\nUltimately the desire is for protocols to be defined that can work on top of TCP, HTTP/1, HTTP/2, WebSockets and possibly others like UDP. \r\n\r\n#### Java Interfaces and Reference Implementation\r\n\r\nJava interfaces for exposing the various use cases using Reactive Streams interfaces would be very powerful to allow a standard interop for Reactive Stream IO.\r\n\r\nIt is not expected to have anything more than interfaces defined, but a reference implementation with unit tests to prove functionality should be included. \r\n\r\n#### JavaScript Interfaces and Reference Implementation\r\n\r\nSimilar desire as for Java above.\r\n\r\n#### Network TCK\r\n\r\nAlong with the network protocol I would expect a test suite to validate implementations. \r\n\r\n\r\n## Moving Forward\r\n\r\nAs a first step I'd like to determine if there is sufficient interest and that this is not insane, completely naive and wrong, or reinventing something that already exists. \r\n\r\nIf we get through that part, I'll work with you all to create more concrete Github issues to start designing and making this happen.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/comments/79263205","html_url":"https://github.com/reactive-streams/reactive-streams-io/issues/1#issuecomment-79263205","issue_url":"https://api.github.com/repos/reactive-streams/reactive-streams-io/issues/1","id":79263205,"user":{"login":"rkuhn","id":470469,"avatar_url":"https://avatars.githubusercontent.com/u/470469?v=3","gravatar_id":"","url":"https://api.github.com/users/rkuhn","html_url":"https://github.com/rkuhn","followers_url":"https://api.github.com/users/rkuhn/followers","following_url":"https://api.github.com/users/rkuhn/following{/other_user}","gists_url":"https://api.github.com/users/rkuhn/gists{/gist_id}","starred_url":"https://api.github.com/users/rkuhn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rkuhn/subscriptions","organizations_url":"https://api.github.com/users/rkuhn/orgs","repos_url":"https://api.github.com/users/rkuhn/repos","events_url":"https://api.github.com/users/rkuhn/events{/privacy}","received_events_url":"https://api.github.com/users/rkuhn/received_events","type":"User","site_admin":false},"created_at":"2015-03-13T19:08:49Z","updated_at":"2015-03-13T19:08:49Z","body":"@danarmak It would of course be trivial to implement RS semantics on a lossless duplex transport, but as far as I understand this is not the only goal of this effort. It is meaningful to layer RS semantics on top of a transport that is by itself not yet reliable or back-pressured—I’d venture to say that this is the more interesting goal."}}