- From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Apr 2016 14:08:15 +0000
- To: public-secondscreen@w3.org
But as I understand, one would not need to trigger any action to enter 'connected' state, it's up to the UA. What action did you have in mind? Currently, the receiving context will create a 'connected' PresentationConnection object and fire 'connectionavailable' with it. If there's an error establishing connection, either the event is not fired at all (if reading the algorithm steps, establishing the actual connection is a step before queuing the event) or the connection changes the state to 'closed' (if reading the afterwords saying that the event should be fired as soon as the PresentationConnection object is created). With the 'connecting' state as the initial one, the PresentationConnection is created and the event is fired as soon as the UA gets the connection request. Then it either changes its state to 'connected' if everything went ok or 'closed' if something failed. On the other hand, is there a good use case why the presentation page should get notified about this? I'd say the UA handles the connection request and only creates the PresentationConnection with 'connected' state and fires the event if the connection is successful. Otherwise, the page shouldn't even know there was a request to connect - it's left up to the UA to handle. -- GitHub Notification of comment by avayvod Please view or discuss this issue at https://github.com/w3c/presentation-api/issues/283#issuecomment-212935866 using your GitHub account
Received on Thursday, 21 April 2016 14:08:17 UTC