See also: IRC log
<ryandavis> can someone remind me what the password is?
<inserted> scribenick: cpn
cpn: Runs through the agenda
https://www.w3.org/wiki/TV_Control/Use_Cases
cpn: Jean Pierre and I have
updated some of the radio uses
... There are some new requirements, around content
redistribution and permissions for web sites to present
broadcast content
... Also for the use of schema.org metadata, both in publishing
and consumption of this data
alex: we support these
requirements for content redistribution
... there are also new radio requirements: for tuning, channel
scan, presentation using <audio>, registering for change
notifications
... control of service playback and status
... also service metadata, we should be able to deliver basic
metadata, service ids, genres, also technical metadata eg,
bearer, signal quality, and registering changes in these
... it's basically the same as we have for TV in the API
... something new is the use cases for radio applications: we
have dynamic label, or radio text, and slideshow
... the API should be able to register callbacks for these
dynamic label and slideshow events
... this is an important use case from our point of view, to
deliver title and artist information
... the API should also deliver what I call MOT header
information, including click-through URLs on images
... lastly, the EPG use cases look OK, and in principle it's
the same as TV
... there are other applications besides dynamic label and
slideshow (eg, journaline), but i think those are the most
import
ryan: i agree with this, and will
see if we can add anything
... the genivi media manager has requirements along these
lines, for auto
cpn: alex, have you been thinking about the necessary changes to the api?
alex: yes, but how best to do
that - github issue?
... at the moment we have TVManager, TVSource, TVTuner, and why
we have each of these
... the idea of having a tuner and a source seems ok
... for the radio use case, do we stick with the naming -
TVSource, TVTuner, or should we use a more agnostic naming
convention
... i could live with the existing approach, but looking at
TVSourceType we'd need to add some non-TV sources here, e.g,
T-DMB, needed to support DAB, FM, DRM, HD Radio
... the next change would be in TVChannel, how should we
architect the API? Integrating radio may not be the best
approach, some of the technical attributes don't make sense for
radio
... so i think we need a distinction between a TV channel and a
radio channel
... I could write this up and put it into GitHub
ryan: i like the current setup with manager, tuner, etc
a source could be a tuner with a collection of APIs
alex: the existing API models what's physically going on, a TV can have a tuner with DVB-C and DVB-T sources
cpn: i think i'd us to rename the objects to make them more generic
alex: for the channel interface, we could have a base interface, then inherit from this to get TV and radio specialisation
cpn: i think describing the proposed changes on GitHub is the next step
alex: i'm happy to do that
cpn: we have the meeting
scheduled for the tuesday at TPAC
... does any want to be able to attend remotely?
alex: i may want to, yes
... ok, i'll work with w3c staff to organise that
ryan: i won't be attending, but i could also join remotely
cpn: i'd like for use to discuss the architectural issues with the API at TPAC, such as the open web vs the device oriented nature of the API
<ryandavis> https://www.w3.org/auto/security/wiki/ASP_TF
cpn: i'll try to send out a proposed agenda for the F2F as soon as possible, so remote people can plan when to join
cpn: i had an action from the last meeting to write some introductory text
https://github.com/w3c/tvcontrol-api/pull/12
cpn: suggestions for improving
this would be very welcome
... francois and i have been putting issues into GitHub:
https://github.com/w3c/tvcontrol-api/issues
... please add your views or suggestions as comments to
these
<ryandavis> here is the link for the Media Manager from Genivi to look over https://at.projects.genivi.org/wiki/display/PROJ/Media+Manager
cpn: or suggest changes to the spec text itself
Yann: I have a particular issue, which I'll raise on GitHub
Hyojin: I'll discuss the radio changes internally and come back to the WG if we have any concerns
cpn: next call will be August 23
- Adjourned -
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i/Runs through/scribenick: cpn Found ScribeNick: cpn Inferring Scribes: cpn Present: YoungSun Yann Chris Alex Ryan Hyojin Got date from IRC log name: 26 Jul 2016 Guessing minutes URL: http://www.w3.org/2016/07/26-tvapi-minutes.html People with action items:[End of scribe.perl diagnostic output]