Hi Simone! :)
I think James conveyed basically everything I had in mind to respond, but I felt compelled to address the following: >Forcing users to implement Subscribers or Processors (because that's what the API requires, despite having a few utilities that cover the common cases) is way more difficult for users than just passing around a Publisher. Simply because an API has an interface type as an parameter or a return value does not (in my mind) in any way imply that end-users (think: application developers) are required, encouraged, forced, or otherwise, to create their own implementations of said interface types to be able to use it. What is pretty awesome though is if someone has a need for functionality not provided elsewhere, is that Reactive Streams has a formal specification and a—free and readily available—TCK to guide implementors to implement them correctly. On Mon, Apr 2, 2018 at 2:09 PM, Simone Bordet <simone.bor...@gmail.com> wrote: > James, > > perhaps I was not clear enough. > > The JDK will offer an API based on RS, so that's a user-facing API. > > Given that, the question is whether the surface of exposition to users > when they want to use the JDK HttpClient API should be limited to > Publishers, or expanded to Publishers, Subscribers and Processors. > My suggestion was to limit it to Publishers only. > Forcing users to implement Subscribers or Processors (because that's > what the API requires, despite having a few utilities that cover the > common cases) is way more difficult for users than just passing around > a Publisher. > > It is by exposing Publishers only that you get rid of the need for > users to implement any of the RS interfaces to interoperate with other > libraries. > > I'm not sure I buy your opinion on the RxJava2 and Reactor libraries > (peace! :) > Both have plenty APIs to create a Flowable/Flux from Publishers, and > almost none to handle Subscribers: Publishers are exposed, Subscribers > hidden. > I don't see any confusion. > > Thanks ! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz > -- Cheers, √
