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

On Tue, Apr 17, 2018 at 6:28 PM, Chris Hegarty wrote: > On 17 Apr 2018, at 17:52, Viktor Klang wrote: > > ... > > There is technical and non-technical effort required. It is non-trivial. > > That said, we’re making every effort possible to move this forward. > > > > Hi Chris, > > > > how can we

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

On 17 Apr 2018, at 17:52, Viktor Klang wrote: > ... > There is technical and non-technical effort required. It is non-trivial. > That said, we’re making every effort possible to move this forward. > > Hi Chris, > > how can we help? Thank you for asking, but I think we have it under control. I h

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

On Tue, Apr 17, 2018 at 9:55 AM, Chris Hegarty wrote: > Simone, > > > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > > > >> ... > > > > Out of curiosity, is this code implementing the ReactiveStreams TCK > > (in its Flow declination) ? > > The code should be compliant with the RS TCK. > > > I

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

Simone, > On 16 Apr 2018, at 18:47, Simone Bordet wrote: > >> ... > > Out of curiosity, is this code implementing the ReactiveStreams TCK > (in its Flow declination) ? The code should be compliant with the RS TCK. > I ask because I have recently implemented it for Jetty's Reactive > HttpClien

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

Chris, On Mon, Apr 16, 2018 at 7:09 PM, Chris Hegarty wrote: > Hi, > > Here are refreshed links to the latest code in the sandbox: > > http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html > http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/ > > Incl

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

Hi, Here are refreshed links to the latest code in the sandbox: http://cr.openjdk.java.net/~chegar/httpclient/03/javadoc/api/java.net.http/module-summary.html http://cr.openjdk.java.net/~chegar/httpclient/03/webrev/ Includes: a) Changes to address the two issues raised by Simone during the

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

Michael, Chris, Thanks for your feedback, indeed with PublishingBodySubscriber, it works also for streaming use cases and it provides the behavior I was trying to achieve. So +1 for inclusion of JDK-8201186 in JDK 11. On Thu, Apr 5, 2018 at 6:12 PM, Chris Hegarty wrote: > Hi Sebastien, > > > On

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

Hi Sebastien, > On 5 Apr 2018, at 11:07, Sebastien Deleuze wrote: > > Hi, > > I am currently implementing a draft support for JDK new HTTP client in Spring > Framework 5 [1] (using JDK 10 for now) in order to be able to leverage it as > a WebClient [2] engine. Great that you are trying this

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

Sebastien, The answer depends on the particular HttpResponse.BodySubscriber/Handler implementation supplied to the sendAsync() call. Some of the simpler ones which return aggregate/completed objects like String, or byte[] do not appear to stream and the response body is not returned until afte

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

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

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

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 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

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, On Wed, Mar 21, 2018 at 9:33 PM, Chris Hegarty wrote: > Hi, > > This is a request for review for the HTTP Client implementation - JEP 321. It is my understanding, and that of the ReactiveStreams (RS) people I spoke with, that both the RS API and the higher level API based on RS (such as thos

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

On 28 March 2018 at 18:50, Wenbo Zhu wrote: > >>> Any useful RS support will have to involve some application-level >>> protocols. >>> >> >> I completely disagree with this statement. As someone who has been >> involved in/led the implementation of multiple WebSocket clients and >> servers (inclu

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

On 23 March 2018 at 04:36, Wenbo Zhu wrote: > > +1 > > Message-based flow-control is unspecified by the websocket protocol; and > exposing byte-based flow-control (via RS) as part of the WS API seems a > rather questionable approach. > No one is suggesting a byte based flow control mechanism, RS

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

Hi Chris, Requiring a third party adapter for using Reactive Streams for WebSockets is not the end of the world, so I don't want to push this too hard, we can just agree to disagree. But there were a few small questions in your reply that I'll answer. > Will their backpressure mechanisms map to e

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

Simone, Thank you for you comments. On 23/03/18 08:28, Simone Bordet wrote: Hi, On Thu, Mar 22, 2018 at 1:57 PM, Chris Hegarty wrote: Rather, I think that there should be a built in helper that allows Reactive Streams to be added on top, I fully agree that a Reactive Streams WebSocket abs

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

Hi, On Thu, Mar 22, 2018 at 1:57 PM, Chris Hegarty wrote: >> Rather, I think that there should be a built in helper that allows Reactive >> Streams to be added on top, > > I fully agree that a Reactive Streams WebSocket abstraction should be > built on top. Where I disagree is that it needs to b

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

James, Thanks for your reply. > On 22 Mar 2018, at 00:28, James Roper wrote: > > Hi Chris, > > I'm still really keen to see an option provided out of the box for using > Reactive Streams with the WebSocket API. What we are delivering in JEP 321 is mainly an HTTP Client API ( you get a small

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

Hi Chris, I'm still really keen to see an option provided out of the box for using Reactive Streams with the WebSocket API. Note that I'm not proposing that anything be changed about the existing API, I understand fully that you want to provide a full powered API that offers the full range of WebS