Hi Pavel,
On 9/2/2015 4:40 PM, Pavel Rappo wrote:
Hi Roger, thanks for looking at this!
On 1 Sep 2015, at 17:05, Roger Riggs wrote:
- The Incoming class combines separate functions that would be easier to
use if the methods were directly on the Builder.
...
|WebSocket ws = WebSocket.new
On 3 Sep 2015, at 11:49, Andrej Golovnin wrote:
> Hi Chris,
>
>> Will adding the ability to send ping(ByteBuffer) be sufficient for your
>> usage? If so, then I think we should add it, but not pong. The
>> implementation will automatically send a pong message in response to
>> receiving a p
Hi Chris,
> Will adding the ability to send ping(ByteBuffer) be sufficient for your
> usage? If so, then I think we should add it, but not pong. The
> implementation will automatically send a pong message in response to
> receiving a ping. OK?
Yes, ping(ByteBuffer) is sufficient for us.
Best
On 3 Sep 2015, at 10:13, Andrej Golovnin wrote:
> Hi Pavel,
>
>> 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 pon
Hi Pavel,
> 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?
We use pings to ensure that firewal
Hi Michael,
> Can you explain why you need j.n.Proxy rather than the
> String/InetSocketAddress
> combination proposed for HttpClient?
String is not type safe. And allowing to define proxy only for the
specific protocol is not enough from my experience. Sometimes you have
to choose proxy based on
