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

[Wenbo Zhu]

On Thu, Mar 22, 2018 at 5:57 AM, Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> James,
>
> Thanks for your reply.
>
> > On 22 Mar 2018, at 00:28, James Roper <james at lightbend.com> 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 footprint, high performant, low-level, WebSocket
> API for free ). It has taken a long time to get to this point in the
> project, where we are close to requesting that it be Proposed
> To Target for Java SE 11.
>
> > Note that I'm not proposing that anything be changed about the existing
> API,
>
> Ok, good.
>
> > I understand fully that you want to provide a full powered API that
> offers the full range of WebSocket features with very high performance, and
> mapping that to the Reactive Streams API goes against that.
>
> Yes, it does.
>
> > 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 be done in Java SE, let
> alone in JEP 321.
>
+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.

Any useful RS support will have to involve some application-level
protocols.



> > with the understanding that such a helper will limit the capabilities
> and performance when its used - eg, the range of options for closing, range
> of options for how errors are handled, and perhaps introduce some small
> performance penalties such as additional allocations and/or buffer copies.
>
> That is a whole set of comprises and decisions that would need to
> be considered.
>
> > The use case here is how well this API will interact with other APIs.
> WebSockets are rarely used in isolation from other technologies. Most non
> trivial usages of WebSockets will involve plumbing the WebSocket API to
> some other source or sink of streaming data - for example, a message
> broker, a database, perhaps a gRPC stream to another service.
>
> I could well image a set of vertical-market specific libraries being built
> on top of the WebSocket API, and that is how it should be. In this
> specific area, providing the lowest level API is an enabler for others.
>
> > The question is, how difficult will it be to connect those two APIs?
>
> I imagine some work may be required, but certainly much less than
> without the WebSocket API.
>
> > Will their backpressure mechanisms map to each other easily?
>
> I see no reason that it should not. Are you aware of any?
>
> >  Will their failure handling and error handling semantics map to each
> other easily?
>
> I see no reason that they should not. In fact, most higher-level APIs
> provide more coarse grain error handling.
>
> > How many lines of boilerplate will it take to hook them up?
>
> I guess that depends on the particular library's functionality, will it
> support/handle/expose partial message delivery, buffering, etc. I
> don’t see this as boilerplate though.
>
> > If the WebSocket provides an option to use Reactive Streams, then for
> any other sources/sink of streamed data that support Reactive Streams,
> application developers will have an option where the answers are guaranteed
> to be yes without the developer having to do any mapping themselves, and
> the lines of code to do that will be one.
>
> Sure, if one has a higher-level library that works with Reactive Streams,
> and one wants to use WebSocket as a transport, then it would be little
> work if Java SE provided a Reactive Streams interface to WebSocket.
> There are also vertical-markets using WebSocket, but not using Reactive
> Streams.
>
> At this point in JEP 321, I do not want to increase the scope of the
> project
> to include a Reactive Streams interface for WebSocket. This is something
> that can, and should, be considered separate to JEP 321. It could follow
> in a future release if deemed appropriate, or not, but adding it at this
> point
> will add risk to JEP 321, which I am not willing to do.
>
> -Chris.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180322/8ba33b3c/attachment.html>