- 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