+1 with Chris' suggested rewording.
Roger
On 6/21/2016 7:45 AM, Chris Hegarty wrote:
On 21 Jun 2016, at 12:21, Pavel Rappo wrote:
Hi,
Let me try again to propose the following set of changes:
http://cr.openjdk.java.net/~prappo/8156742/webrev.02/
This mainly looks fine, just a small comme
> On 21 Jun 2016, at 12:21, Pavel Rappo wrote:
>
> Hi,
>
> Let me try again to propose the following set of changes:
>
> http://cr.openjdk.java.net/~prappo/8156742/webrev.02/
This mainly looks fine, just a small comment:
- WebSocket.java
"Or to close abruptly call {@link #abort()}.” Rat
Hi,
Let me try again to propose the following set of changes:
http://cr.openjdk.java.net/~prappo/8156742/webrev.02/
The difference between this version and the previous one is that there are no
controversial changes to onClose method [*]. This version also removes
`sendText(Stream message)` whi
> On 3 Jun 2016, at 14:58, Simone Bordet wrote:
>
> The implementation should reply to a Close frame with a Close frame
> with the same code.
> Applications do not need to call sendClose() from within onClose().
It's just this thing can be done. We can't prohibit sending a Close message from
wi
Hi,
On Fri, Jun 3, 2016 at 3:36 PM, Pavel Rappo wrote:
> The implication is that you won't be able to do this (for example):
>
> void onClose(WebSocket webSocket, int statusCode, String reason) {
> webSocket.sendClose(statusCode, reason);
> }
>
> Just because the received statusCo
Simone,
Based on the answers you've provided, careful thinking and re-reading
appropriate parts of the RFC, I think we might find the following solution a
good compromise. (Please note that here I'm only talking about Close message
representation. Other topics discussed, like returning CS/CF from
Hi,
On Thu, Jun 2, 2016 at 10:40 PM, Pavel Rappo wrote:
> 1. Are there any cases where the app needs to know that Close message was in
> fact
> empty?
Not that I know.
> 2. Does the app behaviour (especially, parsing the reason phrase/description)
> depend on the status code?
Not much really.
Simone,
> On 2 Jun 2016, at 14:09, Simone Bordet wrote:
>
> I am not opposed to have a utility method sendClose() parameterless,
> but I don't think that it's worth an Optional in onClose(), given the
> semantic defined by 7.1.5.
It all boils down to how apps use contents of Close messages they
Hi,
On Thu, Jun 2, 2016 at 2:51 PM, Pavel Rappo wrote:
> Regardless of your API proposal, where did you find that in the RFC?
Duh, I misread the RFC.
It says that *if* there is a body, then there is a code.
However, in 7.1.5:
"If this Close control frame contains no status code, _The WebSocket
> On 2 Jun 2016, at 13:00, Simone Bordet wrote:
>
> Furthermore, I'm not convinced there should be a parameterless sendClose().
> The WebSocket protocol itself *mandates* that the Close message must
> have a code
Regardless of your API proposal, where did you find that in the RFC?
Here's what I
Hi,
On Thu, Jun 2, 2016 at 1:24 PM, Pavel Rappo wrote:
> Good point. On the other hand, I was wondering if their semantics is
> definitely
> bound to WebSocket Protocol itself? i.e. can they be reused to indicate
> subprotocol issues, or pre-agreed format, etc.?
>
> 1002
>
> 1002 indicates
Hi,
On Thu, Jun 2, 2016 at 12:27 PM, Pavel Rappo wrote:
> OK. The only thing is that I would leave returned CS from onPing/onPong.
> Remember we discussed that CompletionStage (or CompletableFuture) serves the
> purpose of an asynchronous feedback: "Hey, I'm done with this data". I think
> this w
Simone,
> On 31 May 2016, at 23:05, Simone Bordet wrote:
>
> I think this class exposes too many failure codes that applications
> *must not* be able to use.
> For example, 1002 is not something that the application can ever send,
> only the implementation can, and having a public API to create
Simone,
> On 1 Jun 2016, at 18:31, Simone Bordet wrote:
>
> I'm not sure it's worth encouraging to write application data from a
> onPing() or onPong() listener.
> My take on the issue is that upon receiving a Ping, the implementation
> should send a Pong "as soon as it is practical".
> I don't
Hi,
On Wed, Jun 1, 2016 at 2:26 PM, Pavel Rappo wrote:
> Simone, may I ask you what you think about current `Listener.onPong()`
> behaviour? Do you think it should also send Pong unconditionally upon
> completion
> of returned CS?
I'm not sure it's worth encouraging to write application data fr
Hi Pavel,
Many good improvements
WebSocket:
- CloseReason.of; line 1187: the new constructor of(ByteBuffer) is
using IllegalArgumentException inappropriately
(And other constructors too)
Since the data some off the wire; it is not really the callers fault
if it is too short or too lo
> On 1 Jun 2016, at 15:17, Pavel Rappo wrote:
>
> On the stream thing, well... If you say it's a rare use case, I say let's hear
> more people. I don't have much experience working with WebSocket as a user,
> so I
> would like to listen to people who have it (like yourself). YAGNI is one of my
Simone,
I'm having second thoughts on it. I think you're right about `onClose`
behaviour.
Moreover I now understand `onPing` should behave similarly.
The only difference is that replying with Pong should not be correlated with an
any feedback (e.g. completion, return, etc.) from `onPing` method
Hi Simone, many thanks for taking a close look at this!
> On 31 May 2016, at 23:05, Simone Bordet wrote:
>
> * What is interface Text for ?
> If it does perform a bytes-to-chars conversion, then offering
> asByteBuffer() can be easily done by the application.
> A websocket implementation must ch
Hi Pavel,
one comment:
http://cr.openjdk.java.net/~prappo/8156742/webrev.01/src/java.httpclient/share/classes/java/net/http/WebSocket.java.udiff.html
The CloseReason is constructed with read only Buffer as following:
+ private CloseReason(WSCloseCode code, String description, ByteBuffer
d
Pavel,
On Tue, May 31, 2016 at 7:25 PM, Pavel Rappo wrote:
> Hi,
>
> Could you please review the following change for JDK-8156742?
>
> http://cr.openjdk.java.net/~prappo/8156742/webrev.01/
Comments on the API only.
Looks much cleaner, good job.
I like WebSocket.request(long) being reinstated, a
21 matches
Mail list logo
