- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Feb 2016 19:53:59 +0000
- To: public-secondscreen@w3.org
Trying to generalize this beyond WebSockets a bit, the use case for closing seems to be the following: - One of the parties (A) in the PresentationConnection calls `close()`. - The other party (B) will be allowed to transmit messages while the request to close is sent to B. - A wants to receive these final messages from B. - Once B gets the close request, it notifies A that it's done sending and and A's connection can transition to `closed`. This could be useful, perhaps B would transmit some state to help A reconnect in the future. However, there's no guarantee that A will receive them, in case the connection is closed by navigation, termination, or error (i.e., a reason other than `close()`). Also, B could be misbehaving: spamming A with messages and ignoring the request to close. We would probably need to specify that the close event must happen within a reasonable time, even if there are pending messages. -- GitHub Notification of comment by mfoltzgoogle Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/240#issuecomment-178160148 using your GitHub account
Received on Monday, 1 February 2016 19:54:01 UTC