See also: IRC log
<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?
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> GENIVI 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> W3C 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> GENIVI 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.
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 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> Automotive Media Tuner Use Cases
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> 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 http://www.w3.org/2016/06/28-tvapi-minutes.html#action02]
<kaz> minutes from the latest call
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
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> vehicle information service spec draft
Kaz: There's some discussion on whether to support sessions and/or transactions.
<kaz> MMI Architecture
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 http://www.w3.org/2016/06/28-tvapi-minutes.html#action03]
Chris: Any other comment?
... Next call is 26th of July
[Call adjourned]