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

> * Controlling session wishes to leave the presentation (without 
terminating it).
>  * This case is not handled by the API.
>  * The controlling page could discard the session, which could cause
 the corresponding session on the presenting page to transition to 
closed. This would need to be spelled out.
>  * Or we could add a specific session.disconnect() method.

I think we need to support this scenario. And I don't think that 
relying on GC is a good solution for how to support it. Generally 
speaking, relying on GC to clean up "heavy" resources, like open 
sockets, is not a good idea since in the world of modern generational 
GCs it can take a very long time before an object is GCed. This is why
 we've added .close() on Blob for example.

I would also somewhat argue that in the scenario where multiple 
parties are connected to the same TV, it feels somewhat strange that 
the "default action" is that when one of those connections are 
explicitly (rather than accidentally) ended, that the application on 
the TV is terminated, even though other people are still connected.

But I think that I might be biased here because my mental model is 
that a PresentationSession is more of a "connection" rather than a 
"session". So this is probably coloring my judgement here.

Anyhow, "default" behavior aside, I think there are two ways that we 
can address the use case of allowing explicitly disconnecting without 
closing the application running on the TV:
* Have separate functions on the PresentationSesssion interface for 
disconnect-and-close-presentation and 
disconnect-but-don't-close-presentation.
* Add API on the presentation side which allows the presentation to 
decide if it should be closed when a connection is explicitly 
disconnected.

Technically we could even do both solutions above, though that seems 
somewhat unnecessary.

I can live with either (or both) of these solutions since I think they
 effectively have the same capability-set. 

However I'm somewhat in favor of the latter. Basically I think the 
presentation has access to more of the state needed to make a decision
 about if the presentation should be closed or not. For example it has
 awareness of other connections, or if the application might be in a 
state where the user might experience data-loss if the application is 
closed right now.

I.e. it looks nicer to me to let the application on the TV make the 
ultimate decision about if it should be closed or not when a 
connection is explicitly terminated.

This is why I propose that we add an event like 
"lastsessionterminated". This event would be fired when all active 
sessions has transitioned into the "terminated" state. The default 
action of this event would be to close the application on the TV. This
 has several nice properties.
* The default behavior of calling .close() when there is only one 
controller attached to the TV is unchanged. Calling .close() in that 
scenario will close the application.
* The default behavior when multiple parties are connected is that the
 application is closed when the last controller calls .close()
* The application on the TV gets to make the ultimate decision about 
when the application is closed. (Unless the user overrides by closing 
the application through other means of course.)
* The PresentationSession API continues to match WebSocket and 
RTCDataChannel, i.e. we still have just .send()/onmessage/.close() and
 with those functions behaving the same across all three interfaces.

But I could also live with any of:
* Adding a PresentationSession.disconnect()
* Having PresentationSession.close() just close the connection and 
PresentationSession.end() also closing the application on the TV. 
* Adding a "sessionterminated" event which is fired any time a session
 is explicitly ended and whose default behavior is to close the 
application on the TV. 
* Probably others :)

-- 
GitHub Notif of comment by sicking
See 
https://github.com/w3c/presentation-api/issues/35#issuecomment-133223748

Received on Friday, 21 August 2015 00:13:36 UTC