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

[presentation-api] Add a "starting" state to PresentationConnection

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Oct 2015 20:41:12 +0000
To: public-secondscreen@w3.org
Message-ID: <issues.opened-113095494-1445632872-sysbot+gh@w3.org>
mfoltzgoogle has just created a new issue for 

== Add a "starting" state to PresentationConnection ==
When calling PresentationRequest.start(), it may take some time for 
the presentation to be fully loaded and ready for connection on the 
presentation screen.

In the meantime, the controlling page is unaware of the initialization
 progress of the presentation, since we only resolve the Promise with 
a connected PresentationConnection.  Activities (i.e., media playback)
 will continue in the meantime, while the user has already indicated 
they want the content to be presented remotely, which creates a 
jarring user experience.   If the controlling page were aware that 
presentation was starting, it could pause the media and update the UI 
to show the user what was happening.

@avayvod has proposed adding a starting state to the 
PresentationConnection, with a new start algorithm that would roughly 
go as follows:

1. If the user selects a screen, then resolve the Promise right away 
with a "starting" PresentationConnection. 
2. If the user cancels presentation, reject the Promise.
3. Once the receiving context is fully loaded, transition the 
PresentationConnection to connected.
4. If there is an error loading the receiving context then transition 
to disconnected (or perhaps a new error state).

Messaging would be allowed during the "starting" state in case the 
presentation wants to convey metadata about the chosen screen, or show
 some progress information.

See https://github.com/w3c/presentation-api/issues/214
Received on Friday, 23 October 2015 20:41:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 23 October 2015 20:41:15 UTC