Re: [presentation-api] Would a "closing" connection state be of any use?

Thanks @tomoyukilabs,

Your comment raises an important point, which I overlooked in my 
review of PR #239: it is good practice to continue listening to data 
as long as the underlying connection has not been closed. For 
instance, the Web Socket Protocol (TCP and WebRTC data channels have 
similar expectations, I believe) says:

> By sending a Close frame and waiting for a Close frame in response, 
certain cases are avoided where data may be unnecessarily lost.
> http://tools.ietf.org/html/rfc6455#section-1.4

In particular, the `closed` event should only fire when the client can
 no longer receive any message from the other side, which should thus 
happen once the closing handshake has been completed (ack received 
from the other side, or timeout).

>From an app perspective, it feels strange to be able to receive a 
message after calling `close()`, but that matches how most 
communication protocols seem to operate.

@mfoltzgoogle that is how I had formulated my initial PR #238 (waiting
 for a signal from the other side becore triggering the `closed` 
event), although I had not really done that on purpose. This is no 
longer the case in PR #239, where the `closed` event is fired 
regardless of the status of the underlying connection.

@tomoyukilabs, back to the notion of `closing` state, I am still 
struggling to see how an app would use an explicit `closing` state. 
When would code such as `if (connection.state === 'closing') {...}` be
 needed?

It seems to me that, for all practical purpose, an app would only need
 to have code such as `if (connection.state === 'closed') {...}` or 
`if (connection.state !== 'connected') {...}`, and of course to listen
 to the `closed` event to detect when the connection is closed.



-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at 
https://github.com/w3c/presentation-api/issues/240#issuecomment-171928315
 using your GitHub account

Received on Friday, 15 January 2016 10:31:04 UTC