On 02/09/15 21:17, Andrej Golovnin wrote:
Hi Pavel,
- Where's the .ping() or .pong() ?
* @apiNote Keep-alive features of WebSocket protocol are taken care of
* completely by implementations and are not exposed in this API.
We thought that a high-level API could live without this burden for the user. At
the same time the implementation will definitely have several configuration
parameters, tweaking its behaviour in respect to keep-alive features.
Yes, we've thought about application data that can be carried by those types of
messages, but due to restrictions to their size (125 bytes) and potential
out-of-order delivery we've decided not to expose them as data carriers.
Just because you don’t see usages for it, it does not mean that others don’t
need
it. 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. What I also miss, is the ability to define custom HTTP header
values which should be transmitted during the handshake.
I think we should support both of those capabilities. In an earlier version
of the API we allowed the possibility to build an arbitrary HttpRequest and
then upgrade the response to a websocket. I'm not sure we need that level
of flexibility, but it's interesting to know that custom headers are
required.
And I think you should add an API to define the proxy in case some one use just
WebSocket.newBuilder(String). And please use the class java.net.Proxy to define
a proxy and not just a String and a InetSocketAddress as it is done in
HttpClient.
Can you explain why you need j.n.Proxy rather than the
String/InetSocketAddress
combination proposed for HttpClient?
Thanks
Michael
