Hi,
On Tue, May 10, 2016 at 2:03 PM, Pavel Rappo wrote:
> Hi Simone,
>
>> On 4 Apr 2016, at 20:07, Simone Bordet wrote:
>>
>> In my experience, once you get rid of exception throwing in async API
>> everything becomes much simpler, especially "deep" exceptions related
>> to invalid implementatio
Hi Simone,
> On 4 Apr 2016, at 20:07, Simone Bordet wrote:
>
> In my experience, once you get rid of exception throwing in async API
> everything becomes much simpler, especially "deep" exceptions related
> to invalid implementation internal states.
Am I right saying that you propose that all e
> On 6 May 2016, at 09:16, Felix Yang wrote:
>
> Hi Pavel,
> several comments:
>
> 1. WebSocket.request(long n) is documented as "
>
> @throws IllegalArgumentException if n < -1
> "
>
> It looks meaningless to allow 0.
First of all, the way `request` is defined now is by no means meanin
Hi Pavel,
several comments:
1. WebSocket.request(long n) is documented as "
@throws IllegalArgumentException if n < -1
"
It looks meaningless to allow 0.
2. Some concern on the way of handling close. Consider following scenario.
* obtain a ws connection
* message communications bala
Hello Simone, thanks again for looking into this!
Generally speaking I took some time to get rid of multiple thread dispatching
(incl. internal "Flow"s) and simplified the code a bit. I don't think it's a
very practical thing to do, to get into all details as you could easily compare
two consecuti
Hi,
On Tue, May 3, 2016 at 5:23 PM, Pavel Rappo wrote:
>
> Hello,
>
> Here's an updated webrev with the latest implementation:
>
>http://cr.openjdk.java.net/~prappo/8087113/webrev.04/
Can you please summarize what's different from the previous ?
I had a very quick look, but exception throwi
Strictly speaking, not sending a Pong for every Ping is not against the
protocol
semantics [1]:
If an endpoint receives a Ping frame and has not yet sent Pong
frame(s) in response to previous Ping frame(s), the endpoint MAY
elect to send a Pong frame for only the most recently processed Pi
On 3 May 2016, at 16:23, Pavel Rappo wrote:
> Hello,
>
> Here's an updated webrev with the latest implementation:
>
> http://cr.openjdk.java.net/~prappo/8087113/webrev.04/
This looks much better, more straight forward.
I will ignore any TODO’s and items mentioned in 8155621, which I assume
> On 5 May 2016, at 00:20, Jitendra Kotamraju wrote:
>
> * I see that there is an issue for autoponging. May be this falls under it.
> The default impl of onPing() doesn't send PONG for *every* received PING.
Yes, that's correct. The default implementation sends a Pong in response to a
receive
* I see that there is an issue for autoponging. May be this falls under it.
The default impl of onPing() doesn't send PONG for *every* received PING.
Since it is against the protocol semantics, it forces all applications to
override the default onPing() impl. Is that right ?
It seems to me that th
Hello,
Here's an updated webrev with the latest implementation:
http://cr.openjdk.java.net/~prappo/8087113/webrev.04/
If you're going to review it, please be advised that there is a number of known
API and implementation issues yet to be resolved [1]. More API tests will be
provided in the n
On Sun, Apr 10, 2016 at 10:19 PM, Andrej Golovnin
wrote:
>> On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
>> wrote:
>>> BTW, someone should describe in the JavaDocs of
>>> CompletableFuture#orTimeout()
>>> what would happen when this method is called multiple times on the same
>>> Completable
> On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
> wrote:
>> BTW, someone should describe in the JavaDocs of CompletableFuture#orTimeout()
>> what would happen when this method is called multiple times on the same
>> CompletableFuture with different arguments.
>
> Hmmm the javadoc seems clear en
On Sun, Apr 10, 2016 at 2:00 PM, Andrej Golovnin
wrote:
> BTW, someone should describe in the JavaDocs of CompletableFuture#orTimeout()
> what would happen when this method is called multiple times on the same
> CompletableFuture with different arguments.
Hmmm the javadoc seems clear enough to me
Hi Pavel,
I’m sorry for the late response. I was too busy this week.
> Maybe we could somehow melt what you call CloseReason and CloseCode into a
> single entity? Something like (different name is an option too):
>
>public final class CloseReason {
>
>static CloseReason normalClosur
> On 6 Apr 2016, at 21:28, Roger Riggs wrote:
>
>>> Reader.java:
>>> - line 137: Why should the reader force a new task? Should it be left to
>>> the subscriber to
>>>decide whether its processing is lightweight and can be done immediately
>>> or to re-submit to its own executor.
>>>
>>
> On 4 Apr 2016, at 18:16, Anthony Vanelverdinghe
> wrote:
>
>>> - CompletableFuture sendClose(CloseCode code, CharSequence reason)
>>> change the type of "reason" to String
>> What's the rationale behind this?
> Unlike with the sendText methods, I don't see the added value here. For
> example
Hi Pavel,
On 4/5/2016 2:27 PM, Pavel Rappo wrote:
Hi Roger, thanks for looking into this.
On 5 Apr 2016, at 17:37, Roger Riggs wrote:
It would be helpful if the classnames/filenames reflected the participation in
the WebSocket implementation
to keep them distinct from the HTTP 2.0 implemen
On 6 Apr 2016, at 09:37, Simone Bordet wrote:
> Hi,
>
> On Tue, Apr 5, 2016 at 11:06 PM, Pavel Rappo wrote:
>> Let's suppose we have a ByteBuffer to send. This ByteBuffer contains 1 MB of
>> data, the socket send buffer is 16 KB, the network is not particularly fast.
>> Suppose then the first
Hi,
On Tue, Apr 5, 2016 at 11:06 PM, Pavel Rappo wrote:
> Let's suppose we have a ByteBuffer to send. This ByteBuffer contains 1 MB of
> data, the socket send buffer is 16 KB, the network is not particularly fast.
> Suppose then the first pass fills the full buffer's 16Kb completely. So
> WebSock
Hi Simone,
> On 5 Apr 2016, at 21:16, Simone Bordet wrote:
>
> Hi,
>
> Sure, the caller must not block.
> But there is no need to dispatch to achieve that when all code is
> non-blocking already.
Sorry, could you please explain this to me in more detail? I'm not sure I'm
following.
Let's sup
Hi,
On Tue, Apr 5, 2016 at 9:37 PM, Chris Hegarty wrote:
> I need to get back into the code, but are you counting the calling thread,
> the one invoking sendXXX(), as dispatch 1?
No, that's why I am proposing *zero* dispatches.
> We always need this to
> allow the caller NOT block right.
Sure,
Simone,
On 5 Apr 2016, at 20:25, Simone Bordet wrote:
> Hi,
>
> On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty
> wrote:
On 3 Apr 2016, at 18:43, Simone Bordet wrote:
Threading.
---
WebSocket.sendXXX() calls
MessagePublisher.send(), which dispatches a to
MessagePu
Hi,
On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty wrote:
>>> On 3 Apr 2016, at 18:43, Simone Bordet wrote:
>>> Threading.
>>> ---
>>> WebSocket.sendXXX() calls
>>> MessagePublisher.send(), which dispatches a to
>>> MessagePublisher.react(), which calls
>>> MessageSender.onNext(), which dispatche
Hi Roger, thanks for looking into this.
> On 5 Apr 2016, at 17:37, Roger Riggs wrote:
>
> It would be helpful if the classnames/filenames reflected the participation
> in the WebSocket implementation
> to keep them distinct from the HTTP 2.0 implementation in the same directory.
> For example,
Hi Pavel,
Initial comments, bottom up.
It would be helpful if the classnames/filenames reflected the
participation in the WebSocket implementation
to keep them distinct from the HTTP 2.0 implementation in the same
directory.
For example, Writer, Reader, etc. perhaps a 'Ws' prefix would be
su
Hi,
On Mon, Apr 4, 2016 at 8:45 PM, Chris Hegarty wrote:
> Isn’t this the same as the new HTTP Client in java.net.http, e.g.
> HttpRequest::responseAsync ? Do you think that this should be
> changed also?
I have not looked at the new HTTP client yet, but I will.
In my experience, having one si
On 4 Apr 2016, at 17:00, Simone Bordet wrote:
> Hi,
>
> On Mon, Apr 4, 2016 at 4:02 PM, Pavel Rappo wrote:
>> I see your point. Yes, working asynchronously kind of suggests that we should
>> relay all exceptions through the asynchronous interface (CF in this
>> particular
>> case), simply bec
Hi Pavel
Thanks for your considerate response, replies are inline.
On 4/04/2016 13:08, Pavel Rappo wrote:
Hi Anthony, thanks a lot for looking into this!
On 3 Apr 2016, at 17:45, Anthony Vanelverdinghe
wrote:
Here are my suggestions concerning the public types:
java.net.http.WebSocket
- o
Hi,
On Mon, Apr 4, 2016 at 4:02 PM, Pavel Rappo wrote:
> I see your point. Yes, working asynchronously kind of suggests that we should
> relay all exceptions through the asynchronous interface (CF in this particular
> case), simply because otherwise we would have to handle exceptions in many
> pl
I'm still working my way through the code, but ...
On 04/04/16 15:02, Pavel Rappo wrote:
Hi Simone, thanks for deep dive into this!
On 3 Apr 2016, at 18:43, Simone Bordet wrote:
Throwing exceptions.
---
Given that the API is making use of CompletableFuture, throwing
exceptions instead is in
Hi Simone, thanks for deep dive into this!
> On 3 Apr 2016, at 18:43, Simone Bordet wrote:
>
> Throwing exceptions.
> ---
> Given that the API is making use of CompletableFuture, throwing
> exceptions instead is in my experience not the right thing to do.
> You want to communicate failure via t
Hi Anthony, thanks a lot for looking into this!
> On 3 Apr 2016, at 17:45, Anthony Vanelverdinghe
> wrote:
>
> Here are my suggestions concerning the public types:
>
> java.net.http.WebSocket
> - order the arguments of
> static Builder newBuilder(URI uri, HttpClient client, Listener listener)
Hi,
On Fri, Mar 25, 2016 at 5:21 PM, Pavel Rappo wrote:
> Hi,
>
> Could you please review my change for JDK-8087113
>
>http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
>
> This webrev contains initial implementation and basic tests for WebSocket API.
> Specification conformance & interop
Hi Pavel
Here are my suggestions concerning the public types:
java.net.http.WebSocket
- order the arguments of
static Builder newBuilder(URI uri, HttpClient client, Listener listener)
consistently with the 2-argument method:
static Builder newBuilder(URI uri, Listener listener, HttpClient client
>
>
>
> You see there'a thing. That's why I didn't do it immediately. For example
> let's
> consider a "Sec-WebSocket-Extensions" (a very good illustrative example.)
> RFC 6455 states it very clearly [1]:
>
> The |Sec-WebSocket-Extensions| header field MAY appear multiple times
> in an HTTP
Hi Chris,
> On 31 Mar 2016, at 17:35, Chris Hegarty wrote:
>
> I’ve looked at the API a number of times, and overall I’m happy with it
> ( modulo the known open issues ). Some initial comments.
Thanks a lot for looking into this!
> Generally, I prefer javadoc style comments on members. Even it
On 25 Mar 2016, at 16:21, Pavel Rappo wrote:
> Hi,
>
> Could you please review my change for JDK-8087113
>
> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
I’ve looked at the API a number of times, and overall I’m happy with it
( modulo the known open issues ). Some initial comments.
On 29/03/2016 20:16, Andrej Golovnin wrote:
177 throw new
IllegalArgumentException(String.valueOf(n));
>>
>>Could you please provide a better message for exception here?
>
>What would the purpose be? It's an internal implementation detail. If this
>exception is throw
> On 29 Mar 2016, at 20:16, Andrej Golovnin wrote:
>
> JEP-280 does not apply in this case. But when you rewrite this code to
> use the plain String concatenation, then JEP-280 would apply:
>
> 211 static String toString(Buffer b) {
> 212 return toStringSimple(b)
> 214
Hi Pavel,
>> 215 .append("
>> rem=").append(b.remaining()).append("]").toString();
>>
>> Please use ']' instead of "]”.
>>
>> 222
>> .append("[len=").append(s.length()).append("]").toString();
>>
>> Please use ']' instead of "]”.
>
> I believe since JEP 280 [1
> On 26 Mar 2016, at 11:44, Andrej Golovnin wrote:
>
> src/java.httpclient/share/classes/java/net/http/RawChannel.java
>
> When you don’t plan to have any subclasses of RawChannel, then
> please mark it as final.
>
> 43 private boolean closed;
>
> I think this field should be volatile.
>
Hi Pavel,
I have only cosmetic comments. Please feel free to ignore anything you don’t
like. ;-)
> Could you please review my change for JDK-8087113
>
> http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
src/java.httpclient/share/classes/java/net/http/RawChannel.java
When you don’t plan
Hi,
Could you please review my change for JDK-8087113
http://cr.openjdk.java.net/~prappo/8087113/webrev.03/
This webrev contains initial implementation and basic tests for WebSocket API.
Specification conformance & interoperability testing has been performed with
Autobahn Testsuite [1]. As fo
44 matches
Mail list logo
