W3C home > Mailing lists > Public > public-secondscreen@w3.org > June 2016

Re: [remote-playback] Allow websites to stop the remote playback

From: Anton Vayvod via GitHub <sysbot+gh@w3.org>
Date: Mon, 06 Jun 2016 13:54:14 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-223965673-1465221253-sysbot+gh@w3.org>
What would the Promise mean in the context of `showPicker()` or 
`prompt()`? How would the behavior be defined in the spec w/o biasing 
towards the existing implementations too much?

Seems like something along the following lines:

When ```showPrompt|Picker()``` is called, the user agent MAY present 
some UI so the user could start or stop the remote playback. The 
returned promise will be fulfilled with `true` if user's interaction 
with the UI ends up in a state change (`disconnected` to `connecting` 
or `connected` to `disconnected`), otherwise it will be fulfilled with
 `false` if the state change was cancelled by the user or rejected 
with an appropriate error. Either 'connect to the remote playback 
device' or 'stop remote playback' algorithm MUST be run after 
successful fulfillment of the promise correspondingly to the state 
change initiated by the user.

How does it sound?

How about `requestStateChange()` for the name to avoid any UI in the 
name? I can imagine some persistent permission model where user allows
 an origin to play remotely on the same device and then the user agent
 doesn't have to show any UI.

-- 
GitHub Notification of comment by avayvod
Please view or discuss this issue at 
https://github.com/w3c/remote-playback/issues/4#issuecomment-223965673
 using your GitHub account
Received on Monday, 6 June 2016 13:54:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 6 June 2016 13:54:16 UTC