Simone,
Thank you for you comments.
On 23/03/18 08:28, Simone Bordet wrote:
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.
You have been directly involved in the design of the WebSocket API
as it stands today ( not based on reactive streams Flow ). Are you
now suggesting now that Java SE should provide two programming
models for WebSocket? I think one is more than sufficient.
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.
Writing an efficient HTTP proxy is not the primary use-case for
this API. It is being positioned as a replacement for the legacy
HttpURLConnection API. It needs to be approachable by the average
( whatever that is ) Java developer.
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.
I disagree. WebSocket and HTTP are two distinct protocols, whose
use will likely be very different. I don't see why it is
incongruent to model them in different ways.
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.
Answered above.
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 disagree. The WebSocket API is less approachable by the average
Java developer. It's low-level semantics and use of CompletableFuture,
while appropriate for libraries building on top or using it as a
transport, is acceptable. It is not something that I would expect
the large majority of Java developers ( likely to be retrieving HTTP
resources ) to be as comfortable with.
The substantive point is that the HTTP Client API and the WebSocket
API are targeting two different audiences.
I would like this revision to be taken into consideration, offering an
efficient low-level API for HTTP as well.
The HTTP Client API been based on Flow for for a long time now.
Incubated in JDK 9, and re-incubated in JDK 10. I note, that you
have been following and contributing to JEP 110 and now JEP 321
too ( your contributions have been very valuable, thank you ).
Offering a low-level HTTP API ( akin to that of WebSocket ) will
make the API less approachable to the majority of Java developers.
This is not something that I am comfortable with.
-Chris.
