Hi,
On Wed, Jul 13, 2016 at 9:27 PM, Pavel Rappo wrote:
> The rationale for IAE is that it's a programming error to stick an illegal
> value
> in a method (given the fact the value is illegal is known a priori.)
We agree on the programming error, not on how to report it.
Just because it's a pro
Hi Simone, thanks for the detailed reply (as always)!
> On 13 Jul 2016, at 17:07, Simone Bordet wrote:
>
>>* @throws IllegalArgumentException
>>* if the {@code statusCode} has an illegal value, or
>>* {@code reason} doesn't have an UTF-8 representation not longer
>>
Hi,
On Wed, Jul 13, 2016 at 3:05 PM, Pavel Rappo wrote:
> /**
> * Sends a Close message with the given status code and the reason.
> *
> ...
> *
> * The {@code statusCode} is an integer in the range {@code 1000 <=
> code
> * <= 4999}. However, not all status
It looks like we've agreed on everything except for the status codes and the
spec for what WebSocket does after a CS returned from onClose completes.
May I propose the following spec?
/**
* Receives a Close message.
*
...
*
* A Close message consists of a status c
On 23/06/16 18:09, Simone Bordet wrote:
Hi,
On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote:
But I still think we probably more safe assuming the intersection of our
understandings, rather than a union :-)
Chris and I agreed, so now you're minority :)
Well, I think I kinda talked (off-l
Hi,
On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote:
> But I still think we probably more safe assuming the intersection of our
> understandings, rather than a union :-)
Chris and I agreed, so now you're minority :)
--
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good
Simone, please disregard the link to the test I gave you. My apologies. This
test has nothing to do with starting a new message after a Close message has
been received. It just verifies that the endpoint stops reading after receiving
onClose. So not sending back a Pong is perfectly natural in this
On 23 Jun 2016, at 16:09, Simone Bordet wrote:
>
> Hi,
>
> On Thu, Jun 23, 2016 at 4:40 PM, Chris Hegarty
> wrote:
>> What Pavel is trying to do with onClose is to adhere to the
>> spirit of the RFC, rather than supporting open-ended half-close semantics.
>
> Not sure there is a spirit to RFC
> On 23 Jun 2016, at 16:01, Simone Bordet wrote:
>
> Hi,
>
> However, here's another examples that shows the ambiguity:
>
> |-> sendBinary(huge, true);
> |<- onClose()
>
> The implementation will fragment "huge", or the write will be
> incomplete, so that "huge" is not fully sent yet.
> When
Hi,
On Thu, Jun 23, 2016 at 4:40 PM, Chris Hegarty wrote:
> What Pavel is trying to do with onClose is to adhere to the
> spirit of the RFC, rather than supporting open-ended half-close semantics.
Not sure there is a spirit to RFCs, just interpretations.
I doubt the "spirit" of the RFC was to de
Hi,
On Thu, Jun 23, 2016 at 4:09 PM, Pavel Rappo wrote:
> Is this some kind of a clever sarcasm, designed to point out the ambiguity in
> question?
Nope.
> Because I actually meant the *application*. Consider the following
> flow of events (let's assume a simplified scenario where all CFs from
> On 23 Jun 2016, at 15:36, Simone Bordet wrote:
>
> Hi,
>
> On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty
> wrote:
>> At one point I thought the same, but after, yet another, re-reading of the
>> RFC
>> I disagree. The semantics are somewhat stronger in WebSocket, albeit that
>> the wordin
Hi,
On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty wrote:
> At one point I thought the same, but after, yet another, re-reading of the RFC
> I disagree. The semantics are somewhat stronger in WebSocket, albeit that
> the wording is a little squirrely :
>
> 5.5.1 Close [1]
>
>It SHOULD do so a
Hi Pavel,
I would avoid terms like application and client in any specification or
API description,
it may be that the caller of the API is another library.
The javadoc should focus on the behavior of each method when it is called.
$.02, Roger
On 6/23/2016 10:09 AM, Pavel Rappo wrote:
Simon
Simone,
> On 23 Jun 2016, at 14:48, Simone Bordet wrote:
>
> I think you should not use the word "client" since it's not clear if
> you refer to the application or the implementation.
> Here it can be mistaken for both, but it's really the implementation.
> However, the readers of the Javadocs w
> On 23 Jun 2016, at 14:48, Simone Bordet wrote:
>
> ...
>
> WebSocket's close mechanism is a double half close, like TCP.
> In TCP the semantic is very clear: sideA can half close, sideB can
> continue sending data, sideA will continue reading data, until sideB
> half closes.
> Same semantic i
Hi,
On Thu, Jun 23, 2016 at 2:19 PM, Pavel Rappo wrote:
> Summing up, I would propose to change the whole paragraph to this:
>
> * After a Close message has been received, the {@code WebSocket}
> * will close automatically.
I would remove this. It is clear from the text below *when* the
impleme
Hi Roger,
Thanks for having a look at this!
> On 22 Jun 2016, at 18:03, Roger Riggs wrote:
>
> Hi Pavel,
>
> in general, this treatment is fine, some comments below,
>
>> * When a Close message has been received, the WebSocket Protocol
>> * mandates it is handled in a certain way.
> 'a cer
Hi Pavel,
in general, this treatment is fine, some comments below,
On 6/22/2016 8:39 AM, Pavel Rappo wrote:
Hi,
Here's the updated wording. Could you please have a look at it once again so we
fully agree on it?
What has changed?
1. "WebSocket implementation"/"WebSocket connection" -> {@code
Thanks Joakim,
Yes, that's the plan. I would also add 1015.
Thanks,
-Pavel
> On 22 Jun 2016, at 13:50, Joakim Erdfelt wrote:
>
> On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo wrote:
> *. Please notice the difference between range of status codes accepted in
> `sendClose` and passed to `onClos
On Wed, Jun 22, 2016 at 5:39 AM, Pavel Rappo wrote:
> *. Please notice the difference between range of status codes accepted in
> `sendClose` and passed to `onClose`.
> So basically WebSocket will allow to receive status codes up to 65535
> (inclusive), but will not allow to send them if they are
Hi,
Here's the updated wording. Could you please have a look at it once again so we
fully agree on it?
What has changed?
1. "WebSocket implementation"/"WebSocket connection" -> {@code WebSocket}
2. "Automatically" added to make it clear no user actions needed
3. Fixed typos mentioned by Chris.
4
Thanks Chris, I will update the wording and prepare the actual RFR.
> On 21 Jun 2016, at 09:43, Chris Hegarty wrote:
>
> I think this is good.
>
> Just some ideas to simplify the wording.
>
>* After a Close message has been received, the implementation will
>* close the connection aut
I think this is good.
Just some ideas to simplify the wording.
* After a Close message has been received, the implementation will
* close the connection automatically. However, the client may finish
* sending the current sequence of partially sent message parts, if any.
* To faci
I think this is good Pavel, just a few minor comments.
> On 17 Jun 2016, at 19:37, Pavel Rappo wrote:
>
> ….
> * The WebSocket implementation responds to the received Ping
> * message using a strategy of its choice, but withing the boundaries of
I think this is good Pavel, just a few minor comments.
> On 17 Jun 2016, at 19:37, Pavel Rappo wrote:
>
> ….
> * The WebSocket implementation responds to the received Ping
> * message using a strategy of its choice, but withing the boundaries of
} if already done
*/
default CompletionStage onPing(WebSocket webSocket,
ByteBuffer message) {
webSocket.request(1);
return null;
}
> Begin forwarded message:
>
> From: Pavel Rappo
> Subject: Preliminary RFR JDK-8159053: Improve onPing/onClose beha
Hi,
Could you please [*] review the following change for the upcoming JDK-8159053?
This change addresses:
1. Listener.onClose/onPing behaviour, making the implementation fully*
responsible of protocol compliance. So reactions on onClose/onPing cannot be
overridden/redefined in a Listener
2. Simp
28 matches
Mail list logo
