- From: Tomoyuki Shimizu via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Jan 2016 01:52:26 +0000
- To: public-secondscreen@w3.org
@tidoust Thanks for clarification. It turns out I also misunderstood the task during closing handshake. > Knowing that there is still a pending connection encourages the app to wait in situations where it wants to re-connect to the WebSocket server, perhaps? At least, such a situation may imply that the app tries to close WebSocket connection when the server has been still in the middle of sending something to the app, or that the server might be down or still continue unexpected data transfer. One of best practices for the former case seems to be that the server should notify the app of server's intention to send any data beforehand, within application-level implementation. Otherwise, the server can abort sending data as soon as it has received a close frame from the app. (Note: this may require frame-level handling for the server.) Of course, the app may choose to re-connect and ask the server to send the same data again. In my opinion, exposing the `closing` state may be helpful for the latter case, i.e. use for debugging. For example, if the state of one endpoint remains `closing` for a while, developers can doubt that some error or bug has occurred in the other endpoint. -- GitHub Notification of comment by tomoyukilabs Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/240#issuecomment-173774936 using your GitHub account
Received on Friday, 22 January 2016 01:52:33 UTC