Simone, > On 31 May 2016, at 23:05, Simone Bordet <simone.bor...@gmail.com> wrote: > > I think this class exposes too many failure codes that applications > *must not* be able to use. > For example, 1002 is not something that the application can ever send, > only the implementation can, and having a public API to create a 1002 > CloseInfo is not something you I'd like to see exposed. > Same goes with 1007, which the implementation must detect, not the > application; etc. > I would probably just leave CloseInfo.of(), with the current checks > you are doing extended.
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). > Can't the implementation just synthesize a (1005, "") instead and get > rid of the Optional ? > Also, I think it should return a CF, for the following reason. > Notification of onClose() is a half-close. Applications are entitled > to send data from within onClose(). > For such reason, the implementation cannot send the response close > frame just after the method returns. > It should wait until the application has finished writing, and hence > the need for the CF. Here are some thoughts on this issue. It's a special value. It's not null, yes, but it doesn't seem to be a lot better than it. If we allow this code to be "received", it means we will probably have to allow it also to be sent, as one can simply do this: @Override public void onClose(WebSocket webSocket, CloseReason code) { webSocket.sendClose(code); } Why not? And if users can send it back, why can't they construct it? In any way an implementation will have to maintain this illusion in both directions. Namely, when one sends a Close message with "1005" (and maybe a non-empty reason), the implementation will have to detect it, discard the data and send instead an empty Close message. 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. Thanks, -Pavel