- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Jan 2017 15:31:29 +0000
- To: public-tvcontrol@w3.org
@stevem-tw > The TVSource acts as a proxy for the various hardware and software resources needed to acquire a media stream, although the details of these resources are hidden from the app Just to make sure I got that right. A `TVSource` in this model creates at most one stream. An app won't be able to tune to multiple channels at once using the same `TVSource`, even if it calls `tuneToChannel` multiple times. It needs two `TVSource` instances for that to be possible. Is that correct? When would the user be prompted for permission in regular web applications (type 3)? As a result of a call to `getSource`? That seems needed not to leak information about available sources to arbitrary origins. Delivery type makes sense as a criterion for users to grant permission ("this app wants to access your FM radio, do you agree?"). Quality level does not make a lot of sense ("this app wants to access your HD channels, do you agree?"). We may want to mandate the delivery type constraint to avoid asking the user too generic a question ("this app wants to access your broadcast signals, do you agree?"). Once user grants permission for an app to access a specific delivery type, permission can probably be assumed for further calls to `getSource` (and `isSourceAvailable`) for that same delivery type. Also, the user would not be asked for permission to access a particular channel if it gets prompted after the call to `getSource`, unless we ask her again when calling to `tuneToChannel`. Or do you envision that the channel name could be one of the constraints that could be provided to `getSource`? This may be an edge case, I do not know whether apps will only want to tune in to one particular channel. -- GitHub Notification of comment by tidoust Please view or discuss this issue at https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-273202004 using your GitHub account
Received on Tuesday, 17 January 2017 15:31:40 UTC