James, Thanks for your reply.
> On 22 Mar 2018, at 00:28, James Roper <ja...@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. > 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.
