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

[James Roper]

On 23 March 2018 at 04:36, Wenbo Zhu <wenboz at google.com> 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 flow control
is never byte based (unless you use Publisher<Byte>/Subscriber<Byte>, but
no one ever does that because it's incredibly inefficient). Not even TCP
supports byte based flow control, it's packet based. I'm not sure why
you're raising byte based flow control here.

The WebSocket protocol does have implied flow control semantics by virtue
of the fact that it is layered on top of TCP. The current WebSocket API in
JEP 321 offers frame based flow control using an API very similar to RS,
which for all intents and purposes, is message based flow control, since
I've never actually seen, in the wild, fragmented WebSocket messages be
used. Of course, due to the mismatch of TCP packets, OS buffers and
WebSocket frames, there is lag in the propagation of flow control while
buffers fill up, but it is none the less there.

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
(including Play Framework, Lagom Framework and Akka HTTP), I can tell you
from my experience that after the initial WebSocket handshake, WebSockets
can be offered to application developers as just streams of messages using
Reactive Streams, without any additional WebSocket protocol exposure, and
still be useful for 99% of use cases. It certainly does not have to involve
exposing the protocol to the application, most applications care nothing
about message fragmentation, they care nothing about close codes or reasons
beyond whether the connection was terminated with a success or error, and
they care nothing about pings/pongs. Everything that they do care about,
Reactive Streams gives a way of expressing.

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


-- 
*James Roper*
*Senior Octonaut*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180328/f2b4de2c/attachment-0001.html>