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