WebSocket client API

[Michael McMahon]

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