W3C home > Mailing lists > Public > public-secondscreen@w3.org > September 2015

Re: [presentation-api] Refine how to do session teardown/disconnect/closing

From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
Date: Wed, 09 Sep 2015 19:47:42 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-139025976-1441828062-sysbot+gh@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 

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 

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
Received on Wednesday, 9 September 2015 19:47:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 September 2015 19:47:44 UTC