Re: [tvcontrol-api] Why retrieve a list of tuners instead of just one tuner?

Following some discussion on this, the following additional points 
were raised:

The first issue that was discussed was around the constraints that can
 be applied when getting a source. Obvious ones are source type, video
 resolution, tuning step size (for radio), and possibly channel (so 
that an app can say "give me a source that can play this channel").  
There may be others, but this needs more thought.

Another issue that was discussed was around permissions, and at what 
stage the user should grant permission for an app to be able to access
 the functionality, and how this should be presented to the user.  
This discussion covered several topics that affected the API, 
including:

1. Should an app need user permission to access the channel list? 
Conclusion: yes, because the channel list provides further information
 that can be used for fingerprinting a device.
2. Should separate permissions be needed for "read-only" access to the
 API (i.e. read the channel list and present the current channel) vs. 
"read-write access (i.e. changing the current channel or starting to 
present a new channel)?  Conclusion: no, because we couldn't think of 
use cases where the distinction mattered.
3. What permission should the user actually be asked for, such that 
they will understand the question and give informed consent?  
Conclusion: the user should be asked whether they want to allow access
 to broadcast TV or broadcast radio functionality, rather than 
anything narrower which could be too intrusive.

As a result of this discussion, there was a proposal that the API have
 two separate high-level entry points: one for TV functionality and 
one for radio functionality.  This could be two methods on the Window 
or Navigator object, 
```
Promise<TVManager> getTVManager()
Promise<TVManager> getRadioManager()
```

Note that these are separated by tuner type, in effect: radio channels
 delivered by DVB-T would still be accessed through getTVManager() 
rather than through getRadioManager().  

This has two purposes: first, to make it possible to ask for user 
permission in the way described above, and second to separate out the 
functionality where it makes sense to do so.  For instance, in a 
device that has both an FM tuner and a DVB-T tuner, providing a 
unified channel list that covers both tuners is probably meaningless; 
similarly, an FM or DAB radio device may not support recording, where 
a DVB-T or DVB-S device may do.  

The basic APIs would be the same in both cases, although there may be 
extra APIs which are only applicable in one of the two cases.

Note also that the name "TVManager" is still used in the example 
above, simply because we couldn't think of anything better.  
Alternative suggestions are welcome!


-- 
GitHub Notification of comment by stevem-tw
Please view or discuss this issue at 
https://github.com/w3c/tvcontrol-api/issues/4#issuecomment-274052211 
using your GitHub account

Received on Friday, 20 January 2017 11:35:58 UTC