- From: Francois Daoust <fd@w3.org>
- Date: Tue, 28 Jun 2016 16:18:26 +0200
- To: <public-tvcontrol@w3.org>
Hi all,
The minutes of today's call are available at:
http://www.w3.org/2016/06/28-tvapi-minutes.html
... and copied as raw text below. 3 actions recorded during the call:
ACTION: Alex to provide feedback on the spec for integrating radio use cases based on experience with prototyping
ACTION: Chris to get back to Broadcom's thread to mention the idea of a lower-level API
ACTION: Ryan to investigate internally to complete radio use cases Wiki page as needed
Thanks,
Francois.
-----
TV Control WG call
28 Jun 2016
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Jun/0002.html
See also: [3]IRC log
[3] http://www.w3.org/2016/06/28-tvapi-irc
Attendees
Present
Francois_Daoust, Younsun_Ryu, Chris_Needham, Alex_Erk,
Ryan_Davis, Kaz, Bill_Rose, JP_Evain, Steve_Morris
Chair
Chris
Scribe
Francois
Contents
* [4]Topics
1. [5]Publication as First Public Working Draft
2. [6]Cloud browser use cases
3. [7]Feedback from people at Broadcom
file:///tmp/lynxXXXXFQ5vqK/L8254-4639TMP.html#agenda
file:///tmp/lynxXXXXFQ5vqK/L8254-4639TMP.html#item01
file:///tmp/lynxXXXXFQ5vqK/L8254-4639TMP.html#item02
file:///tmp/lynxXXXXFQ5vqK/L8254-4639TMP.html#item03
* [8]Summary of Action Items
__________________________________________________________
[8] file:///tmp/lynxXXXXFQ5vqK/L8254-4639TMP.html#ActionSummary
<SteveMorris> Unfortunately I can only join the IRC channel
today, not the webex
Chris: [going through the agenda]
... Feel free to raise additional topics as needed
... I've seen some discussions around the TV Control API in the
Cloud Browser TF of the Web and TV IG. I'd like to know if
there are requirements coming from them.
... Also, we had feedback from folks from Broadcom which I'd
like to discuss.
... Any other topic for the agenda?
Publication as First Public Working Draft
Chris: The main issue is to set the purpose and context in an
introduction
... I would hope for somebody to contribute text for that.
... Anyone willing to write some introductory text for the
specification?
... Does anyone else feel that we need to address other issues
before publishing the spec as FPWD.
Alex: The only question I have is whether we can include radio
use cases in the spec before publication as FPWD.
Jean-Pierre: Have you specified something yet for these radio
use cases?
Chris: Not yet
Ryan: I'm still planning to add some text from my perspective.
... I have gone through and tried to cross-reference a lot of
automotive use cases with TV tuner use cases.
... I'm not sure that's useful for you guys from your
perspective.
... I can probably provide a few of them by end of this week.
... I need to reach out to some of my co-workers to see if they
have specific use cases to contribute.
Chris: Overall, this group is looking at how we can source
audio/video media into the browser.
... It's looking at the different media sources and then
provide access to these sources as well as metadata that these
sources may provide.
Ryan: What we've been focusing on with the media tuner
discussion in automotive, is with Genevi.
Chris: It would be great if Alex or Jean-Pierre could take a
look at your use cases and see how best we can cover enough of
the functional requirements in the TV Control API.
Alex: Is the Genivi stuff open?
Ryan: I believe so. The group is closed but I think the spec
will be open and public. I'll get back to you on that. I'm not
part of that group. They opened up the specification for us in
W3C.
... There are lots of common people in W3C and Genivi.
Alex: Can we have a look into it?
... I began to fill the Wiki page for the use cases on that.
... We can extend those use cases.
... Maybe there are some more areas to cover. I haven't looked
at EPG right now but will do so.
<ryandavis> [9]GENIVI IVI Radio Use Cases
[9] https://at.projects.genivi.org/wiki/display/PROJ/IVI+Radio+Use+cases
Alex: Some of the general scanning can be done quite
straightforward.
... It's just a different type of tuner with no video. Nothing
special about it.
Ryan: I added a link just now.
<cpn> [10]W3C TV Control Use Cases
[10] https://www.w3.org/wiki/TV_Control/Use_Cases
Alex: Main question is how to integrate radio text and images?
Jean-Pierre: We all know that radio community is different. Is
it a good idea to merge the two in the same spec?
... I'm not quite sure that people will read it or apply it.
Alex: I think it's not a problem. Why should it be? Even now on
DVB, you could have radio-only services.
Jean-Pierre: The point is you *could* have but we *don't*.
Alex: We have. The ARD has a complete radio service like this.
... It's not a huge movement in the market, but we have first
smartphones with DAB receivers into it.
... People are looking into use cases.
... Currently, we can only use that in a native application,
but it would be fantastic to integrate that in Web browsers.
Chris: My own feeling is that the details of the API might be
sufficiently similar that one spec can cover both.
... A lot of the text in the spec is TV-oriented, but that
seems easy to fix.
... For the FPWD, since it's important to set the scope of the
publication, we should include radio. Whether that means we
need to update the interfaces or simply insert it in the
introduction, I'm less certain.
Alex: I'm busy this week. But after that, I may have some time
to go through the spec and see how I can integrate the work
that we've been doing in our prototype.
Chris: That would be very welcome. Could it be done by next
call in 4 weeks from now?
Alex: At least some comments on parts that I think could be
changed, yes.
Kaz: I just skimmed through Ryan's use case document. On the
left side, there is a link to the media manager and media
control.
... There are some requirements there.
... We might want to think about Genivi managet and control use
cases as well.
Ryan: Yes, I agree. That's why they are there.
... Genivi did a lot of research when they developed these use
cases and maybe they have a draft spec already available.
Kaz: In addition to simply radio tuner, finding a way to
integrate Genivi's media tuning with the TV Control
specification would be great.
<kaz> [11]GENIVI Media Control
[11] https://at.projects.genivi.org/wiki/display/PROJ/Media+Control
Chris: Are there features that fall out of scope of the TV
Control WG charter?
Kaz: Ryan put the link to the GENIVI Software Projects, and
there are links to (GENIVI's) Media Manager which includes its
own Media Control feature. From the Automotive group's
viewpoint it would be nicer if we could handle media tuning in
general, e.g., DVD, smartphones, in addition to radio. The
Automotive group also should have some more discussion which
topics should be brought to the TV Control group, though.
Ryan: Comme use across the board will be the use of
MediaStream.
Chris: This makes me wonder whether we should aim for a higher
level of abstraction than we currently have.
... The ability to source any kind of media regardless of where
it comes from.
... TV tuner, Radio tuner can be included but also collection
from other sources.
... I need to refer back to the WG charter.
Ryan: I think everybody's goal is to play any kind of source.
In the tuning device, the frequency is involved and the details
as to how they switch frequencies matter.
... I like to have a list of sources with different
characteristics depending on the type of source.
-> [12]TV Control WG charter
[12] http://www.w3.org/2016/03/tvcontrol.html
Chris: I just had a look at the charter, this would be in scope
in any case. It's a good fit for this group.
... In terms of next steps on this, maybe we should record some
action.
<scribe> ACTION: Alex to provide feedback on the spec for
integrating radio use cases based on experience with
prototyping [recorded in
[13]http://www.w3.org/2016/06/28-tvapi-minutes.html#action01]
Ryan: I have some of the radio tuner stuff already. It
coordinates with the use cases of the media tuner.
<ryandavis> [14]Automotive Media Tuner Use Cases
[14] https://docs.google.com/spreadsheets/d/1yEZVIqgtxp-HgW3dZx9qnUzwOLgGmzmkGO-pF7m8noc/edit#gid=0
Chris: I suppose reconcialing these different sets of use
cases.
... Alex added some use cases to our Wiki page.
... It would be good to add Genivi use cases that are not yet
covered on that page.
... and ideally cross-reference them
<alexerk> [15]https://www.w3.org/wiki/TV_Control/Use_Cases
[15] https://www.w3.org/wiki/TV_Control/Use_Cases
<scribe> ACTION: Ryan to investigate internally to complete
radio use cases Wiki page as needed [recorded in
[16]http://www.w3.org/2016/06/28-tvapi-minutes.html#action02]
Cloud browser use cases
<kaz> [17]minutes from the latest call
[17] https://www.w3.org/2016/06/22-webtv-minutes.html
Chris: Have new requirements emerged from that discussion?
Kaz: Not yet. The Cloud Browser TF has mainly been talking
about use cases and possible architecture models.
... The requirements discussion will be done a bit later on.
Chris: OK.
Kaz: The architecture discussion possibly includes
communication with the tuner.
... Cloud browser is server-based, server-side tuning would
require communication with the client side.
Chris: OK, thank you for the update
Feedback from people at Broadcom
-> [18]Feedback from people at Broadcom
[18] https://lists.w3.org/Archives/Public/public-tvcontrol/2016Jun/0001.html
Chris: People at Broadcom have been working on an
implementation of the TV Control API specification.
... They have raised an interesting issue.
<kaz> s/brought to the TV Control group, /brought to the TV
Control group, though./
Chris: This is talking about 2 software modules that want to
access tuner capabilities.
... How do these modules negotiate or release the tuner?
... So that the user agent may know that the tuner is available
for other uses.
... At the application level, you can make requests that cannot
be satisfied by the underlying resources.
... What they found is that it's not clear how to handle this
particular use case.
... Two possible solutions: have module A explicitly release
the tuner so that module B can access it.
... or make that more implicit.
... The response that I sent was to suggest to make that
explicit, but maybe there should be more of an implicit
approach where the implementation is able to manage the
resource without putting the burden of the acquire/leave
mechanism on the application.
... Has this issue arisen in other areas?
... Is there an existing pattern that we could follow?
Ryan: I don't know of any existing pattern, but based on
experience, implicit would help recovering from buggy
applications.
Chris: I agree
Steve: As an implementer of the specification, it gives you
more freedom to optimize the use of the resource instead of
relying on the application.
Alex: You cannot rely on application developers to share
resources.
Steve: especially if applications come from different sources.
Chris: What implications does it have on the spec?
... It may either be normative changes or guidance for
implementers.
Kaz: There has been some similar discussion in the Automotive
group, and the group thinks that they should handle 2 levels of
interfaces, high-level and lower-level interfaces.
<kaz> [19]vehicle information service spec draft
[19] https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification
Kaz: There's some discussion on whether to support sessions
and/or transactions.
<kaz> [20]MMI Architecture
[20] https://www.w3.org/TR/2012/REC-mmi-arch-20121025/#LifeCycleEvents
Kaz: Another spec named MultiModal Interactions (MMI) to
integrate speech and other user modalities, also have lifecycle
model for session connections.
... It may be useful for TV Control as well to have two levels
of interfaces and have session support in the lower level.
Chris: So we'd have the current layer for applications. And
then underneath that specification, we'd have another level for
implementers.
... Is that something that would need to be standardized?
Kaz: That's a good question. In the automotive case, the group
feels the industry need it. The TV Control WG needs to discuss
this.
Chris: OK, that's a question I need to put in front of all
participants here.
... At this stage, I don't have a strong opinion either way.
Alex: Isn't that very implementation-oriented?
... Assuming I'm watching a stream for an hour, my app will
never release the tuner. If a second app comes in and requests
access to the tuner, I would expect a kind of modal dialogue
that offers the user the possibility to force the release of
the tuner so that the second app may acquire it.
Chris: Right. I'm also thinking about an application that tries
to render multiple streams at the same time.
... I suppose the failure value in the API will give the
application some clue as to what happens.
Ryan: It could be that the client that wants to claim the
resource can request an override.
... "This is currently in use. Are you sure you want to do
that?"
... If there's one user at home, override would be a good
thing. If there are multiple users, being able to steal the
tuner may not be a good thing.
Chris: From a TV UI point of view, is it a question that the
API presents error information back to the application so that
it can handle contention, or are we talking about a modal
dialogue approach?
... It has implications on the user experience, and interaction
through the TV.
Kaz: I agree with Chris. If the use case is simply switching
from channel A to channel B, then a high-level API should be
enough. However, if we have more advanced use cases to
superimpose channels from small screen to the big screen.
Chris: Yes, that second scenario is what I had in mind.
... Does the specification provide enough information to know
what the problems are? Do we expose that information
beforehands? Or do we let the application try the API and fail?
... I think we need to think about it. What I would suggest is
to follow-up the email thread.
... I'm hoping that the guys from Broadcom will come back to
share their views on the topic.
Kaz: In addition to responding to email threads raised by
Broadcom, maybe we can add a section in the Wiki for advanced
use cases. If there's enough need, we could think about
supporting them.
Chris: I think it would be useful to get feedback on whether a
second level seems needed.
Kaz: And if there's no need, then we can simply concentrate on
the current API.
Chris: Should I reply to the thread to mention that possibility
of a second API?
Kaz: Please do so, yes.
<scribe> ACTION: Chris to get back to Broadcom's thread to
mention the idea of a lower-level API [recorded in
[21]http://www.w3.org/2016/06/28-tvapi-minutes.html#action03]
Chris: Any other comment?
... Next call is 26th of July
[Call adjourned]
Summary of Action Items
[NEW] ACTION: Alex to provide feedback on the spec for
integrating radio use cases based on experience with
prototyping [recorded in
[22]http://www.w3.org/2016/06/28-tvapi-minutes.html#action01]
[NEW] ACTION: Chris to get back to Broadcom's thread to mention
the idea of a lower-level API [recorded in
[23]http://www.w3.org/2016/06/28-tvapi-minutes.html#action03]
[NEW] ACTION: Ryan to investigate internally to complete radio
use cases Wiki page as needed [recorded in
[24]http://www.w3.org/2016/06/28-tvapi-minutes.html#action02]
[End of minutes]
Received on Tuesday, 28 June 2016 14:18:44 UTC