- From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Sep 2015 19:47:42 +0000
- To: public-secondscreen@w3.org
I think we should avoid adding more states and events than we have to. We can always add them later if the developers complain. We discussed the disconnection case before, for example, and always agreed that the UA would try to reconnect and if it fails, there's nothing for the web page to try anymore. So distinguishing between accidental and intended disconnection doesn't seem valuable to me so far. The onsessionsclosed is only useful if we have the default behavior of shutting down the presentation when all the sessions are in terminated state. This might make life easier for the web developers who want this behavior, however I suspect many of them would actually prefer the presentation not to be closed immediately: - the presentation might be doing something on its own (e.g. playing some media on the TV) and will want to stay on and expect the user to reconnect if needed - the sender might want to reconnect to the presentation during navigations and shutting down the presentation on disconnect would be bad in this case too I believe both cases above would be more popular than shutting down the presentation if anything goes wrong. That's why the default behavior on the receiving side should be not to shut down the presentation and give it an option of shutting down itself using window.close(). The ability for the user to stop the presentation vs. just detaching the sender from the receiver is important though so a method on PresentationSession is needed to stop the presentation. I still think we should go forward with three states for the PresentationSession: 'connected', 'disconnected' and 'terminated' - and two methods: disconnect() and terminate(). -- GitHub Notif of comment by avayvod See https://github.com/w3c/presentation-api/issues/35#issuecomment-139025976
Received on Wednesday, 9 September 2015 19:47:44 UTC