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

[Simone Bordet]

Hi,

On Mon, Apr 2, 2018 at 12:39 PM, Chris Hegarty <chris.hegarty at oracle.com> 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 and feedback, on this list, from folk in the Reactive
> Streams community ( that greatly improved interoperability ), and this
> has never come up. Without supporting material, I cannot accept this
> assertion.

Fair enough.
I had my impression by using/designing APIs around RS, but I guess
it's a cat that can be skinned in various ways.

> The HTTP Client deliberately does not expose its Publisher of response
> body data. It instead subscribes the given Subscriber, on behalf of the
> invoking code. There can, and must, be a single Subscriber.  This is a
> simple and safe model, expected to be more readily understood by an
> average Java developer ( than exposing a Publisher ). If Publishers are
> better for interoperability with some RS implementations, then this
> could be addressed by a small addition to the API, as proposed later in
> this mail (see below).

I guess this is the guts of what I wanted to discuss.
I would have preferred to see the Publisher exposed, rather than
having user code to pass a Subscriber to the implementation.
Again, I guess it's matter of personal experience, and again the
current way works, so I can't bring strong arguments against it.

> For interoperability
> with other RS implementations, where the Flow adaptation is being done
> through Publishers, I would expect folk to use something like RxJava2's
> `io.reactivex.processors.PublishProcessor`.  In fact, Daniel just wrote
> something similar in a recent test [1], a handler that makes the
> response body available through a Publisher,
> `BodyHandler<Publisher<List<ByteBuffer>>>`. It is a not a general
> purpose Processor, but a Subscriber that makes its data available
> through a Publisher.

Sure.
Again, my point was more along the lines that providing a Publisher
was more immediately familiar to users of other libraries.
I guess all those libraries have a way to convert a Subscriber to a
Publisher, so no big deal - just feels a little more complicated to
me.

> so it would not take much work to provide an API similar to:
>
> BodyHandlers {
> ..
> public static BodyHandler<Publisher<List<ByteBuffer>>> ofPublisher() {...}
> ..
> }
>
> Does this satisfy your concern?

Yes, a way to convert the Subscriber to a Publisher via a utility
Processor provided by the JDK that users won't need to implement.

> I accept that a carrier would be a more friendly for possible evolution,
> maybe:
>
> BodyHandlerInfo {
>   int statusCode() {... }
>   HttpHeaders responseHeaders { ... }
> }
>
> Does this satisfy your concern?

Yes.
This class could already hold the HTTP version, and possibly in future
other information (e.g. whether the response has a body or not).

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