RFR JDK-8156742: Miscellaneous WebSocket API improvements

Simone Bordet simone.bordet at gmail.com
Thu Jun 2 12:00:10 UTC 2016


Hi,

On Thu, Jun 2, 2016 at 1:24 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> Good point. On the other hand, I was wondering if their semantics is definitely
> bound to WebSocket Protocol itself? i.e. can they be reused to indicate
> subprotocol issues, or pre-agreed format, etc.?
>
> 1002
>
>       1002 indicates that an endpoint is terminating the connection due
>       to a protocol error.
>
> 1007
>
>       1007 indicates that an endpoint is terminating the connection
>       because it has received data within a message that was not
>       consistent with the type of the message (e.g., non-UTF-8 [RFC3629]
>       data within a text message).

These 2 codes in particular refer to the WebSocket protocol itself.
Applications cannot reuse them for their own higher-level protocols.

Note that I mentioned those 2 because they were evident, but I think
many other codes are not relevant for applications.

> It's not that obvious that
>
>     ws.sendClose()
>
> and
>
>     ws.sendClose(CloseReason.of(1005, ""))
>
> are the same. I think using `Optional` in this particular case is cleaner.

I disagree. With Optional, you put a burden on *all* cases just to
cover the one single case that is different.

Furthermore, I'm not convinced there should be a parameterless sendClose().
The WebSocket protocol itself *mandates* that the Close message must
have a code, so a parameterless sendClose() by definition has the
meaning of a 1005 code.
If you remove the parameterless sendClose() from the API, you don't
need the Optional anymore, and things will be much simpler.

My point being: let's clean the API to the bare minimum required,
removing stuff until there is nothing left to take away.
Then, we can add utility methods on top of that bare minimum.

-- 
Simone Bordet
http://bordet.blogspot.com
---
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


More information about the net-dev mailing list