Hi, On Thu, Mar 22, 2018 at 1:57 PM, Chris Hegarty <chris.hega...@oracle.com> 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 be done in Java SE, let > alone in JEP 321.
Why is that ? There have been no problems in having Flow-based APIs for the HTTP client, so can you expand on why it would be different for WebSocket ? Not that I would like to have Flow-based APIs in WebSocket (it's indifferent for me, as long as the low-level API is there), I am just wondering why the difference. >> 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. Sure. However, such decisions have been made for the HTTP client. For example, the decision to use Flow-based APIs makes the HTTP client unsuitable to write an efficient HTTP proxy, as it will require data copies. What I see incongruent in JEP 321 is that it provides Flow based APIs for HTTP but not WebSocket, and low-level efficient APIs for WebSocket, but not for HTTP. If the focus is on the HTTP client, I'd rather see efficient APIs for the HTTP client since the HTTP proxy use case is quite common. The design decisions taken for WebSocket (low-level APIs; easily wrappable in Flow APIs; efficient with respect to data copy and allocation; based on CompletableFuture) should have been taken for HTTP with even more importance, given how more popular is HTTP over WebSocket. I would like this revision to be taken into consideration, offering an efficient low-level API for HTTP as well. 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
