Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Simone, There are some RS implementations that offer a user facing API that only offers their equivalent of a Publisher to end users, but that is immaterial to RS, since RS is not an end user facing API, but an integration API. End users should not be implementing their own Publisher/Subscriber

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi Simone, Thank you for your reply. I have inserted inline my replies to specific assertions and comments, but please continue to read on past these as there two concrete proposals further down that address your concerns, as I understand them. > On 30 Mar 2018, at 14:34, Simone Bordet

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

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 a

Re: RFR [11] 8197564: HTTP Client implementation - JEP 321

Hi, On Mon, Apr 2, 2018 at 12:39 PM, Chris Hegarty wrote: > I can find no material supporting this assertion on reactive-streams.org, > or anywhere else for that matter. This is not something that I have, or > any member of the HTTP Client team has, ever come across. We have had > review comments