Define what should happen when device gets disconnected while playing about remote-playback

[mounirlamouri]

CC @avayvod

[avayvod]

Do you have an example when it would matter? CC @mfoltzgoogle

We encourage the websites to stop monitoring availability once in connected state (to save battery and so on), so updating availability callbacks at the time of disconnect shouldn't be important. Once the element disconnects, our example will start watching availability again and that would result in a callback anyway.

[avayvod]

CC @jernoble

[mounirlamouri]

The fact that we encourage websites to stop observing while connected doesn't mean that they will do it and they should be able to observe the change if they want to.

To be clear, I don't think it's a serious issue but it would be good if there was language because this a scenario that will definitely happen:

• user is connected to wifi and has a remote playback session
• wifi drops
• disconnected event is fired and availability callback is called

In my opinion, we should update availability first then fire the event so that when the device is disconnected, the website doesn't try to reconnect because it thinks some device is available.

[avayvod]

This could be an implementation specific detail though as the discovery mechanism could fire availability update to the user agent after the connection mechanism decides the device is lost. Meaning we might not be able to implement this.

[avayvod]

I agree with the order you propose though.

[mounirlamouri]

I would suggest to mention this in the specification at least. It is possible that the order can't be followed because some devices will not fire the event in a way that will allow such implementation but the rule can always be a SHOULD and note that it could not be followed if there are underlying platform limitations.