Hi Andrej, thanks for your reply! > On 2 Sep 2015, at 21:17, Andrej Golovnin <andrej.golov...@gmail.com> wrote: > > Just because you don’t see usages for it, it does not mean that others don’t > need > it.
I couldn't agree more. That's the main reasons we have this review. To tease out things we've completely forgotten, haven't foreseen, etc. > We have an application which already make use of it. And if you don’t add > at least the #ping(ByteBuffer) method, it would not be usable for us and we > will > stay with JSR 356. So you need the ability to send pings and unsolicited pongs. Do you handle pong replies from the server? If so, do you control their arrival times and their consistency with previous pings sent? What about unsolicited pongs from the server? Let me explain why I ask this. To be honest, one of the reasons I though we might not need to expose keep-alive features in the first iteration of the API, is that ping/pong exchange has certain rules to follow [1, 2]. And someone needs to check these rules are followed. It's either implementation or API users or both. Well, I decided it's not a particularly good idea to force API users follow and track these rules. I will have to consider this again. Thanks for pointing out the importance of user accessible pings/pongs! ------------------------------------------------------------------------------- [1] https://tools.ietf.org/html/rfc6455#section-5.5.2 [2] https://tools.ietf.org/html/rfc6455#section-5.5.3 -Pavel
