Hi, On Thu, Jun 2, 2016 at 1:24 PM, Pavel Rappo <pavel.ra...@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
