See also: IRC log
<kaz> scribe: Nilo
<kaz> scribenick: NiloMitra
Agenda includes:
1) choose a better time slot of the call ( for Asia participants)
2) Discuss emails from Colin and Louay
3) How to proceed on use cases and architecture
Introduction and roll calls followed
<bryan> hi, this is Bryan from AT&T. We will be following this work as something potentially of use in our TV services e.g. u-Verse and DirecTV. Maybe providing some use cases and requirements as the work proceeds. In a tangential context, we are heavily focused on evolving networks toward cloud deployment (e.g. through NFV) and hosting end-user apps/clients in the
<bryan> cloud is a potential component of that.
John wants accessibility to be met for the cloud browser environment also
he is specifically looking to ensure that people with disabilities can interact with appropriate UIs
The time slot issue will be clarified with Entrix (Korea) and a proposal made by Alexandra
Alexandra: Cloud browser is not
trivial and a straightforward approach via use cases may not
always be appropriate
... From DT perspective, cloud browser is a run time
environment that runs in the cloud
... A browser in the network leads to a "UI video", which is
the video returned by the cloud browser
... Video and UI Video is sent as one stream, but could also
separate these two where the video is returned from the PVR or
a CDN
... From IPTV telco perspective, could use the second
approach
... Refer to these as the single and double stream, and
describe these on the Wiki
... Also define what a Thin client is
<bryan> Is the draft linked to the wiki yet?
John: Question about UI Video - is it the controls like pause, fast forward, or is it interactive menus?
Alexandra: She means both of
them. Everything which was executed locally in the device is
shifted to the cloud and is executed there just like a standard
browser
... The code is executed in the cloud browser and streamed down
as the UI video
... She will put some explanations on the Wiki.
<bryan> So interactive elements are not directly handled by the thin client, but in the cloud client, and any correlation to mouse etc position/action is handled by the cloud browser? (requiring a stream of thin client UI events?)
Kaz: We should clarify the policy
of queue management during the call - use Q+ to raise your
hand
... Do a basic use case to describe what a cloud browser is
Alexandra: The use cases also
need a relationship to the architecture, which describe the
different approaches to defining a cloud browser
... Work on architecture and use cases in parallel would be her
preferred way of working
<Zakim> JF, you wanted to point to MAUR as some UI requirements for Accessibility
<JF> https://www.w3.org/WAI/PF/media-a11y-reqs/#system-requirements
John: Want to point out that when
HTML5 was introduced, they dealt with accessibility from both
content and system perspective
... It seems like we are creating a cloud media player in the
cloud
Coiln: The player in Active Video also does the accessibility functionality also in the cloud
<bryan> So there needs to be an event stream consumable by the cloud client that includes pointer events and also keyboard or any other accessible interface events.
John: the system requirements is
agnostic on where the accessibility functionality (e.g.,
keyboard) is provided. example - using a keyboard where they
cannot use point and click
... Build out the solution so that it remains accessible for
ALL users
Alexandra: Could it also be a small use case? John: Be happy to build our use cases for accessibility - 4 types: visual, mobility, auditory, cognitive impairments
John: unsure that these 4 user groups can have access
<Zakim> bryan, you wanted to mention the items I noted
Bryan: seems like the user is interacting with a thin client where the user interacts via events (inputs) with the cloud
<JF> +1 to Bryan
Bryan: There should be an appropriate response to all the user inputs from the cloud browser
Nilo: Are thin client and cloud browser equivalent terms?
Alexandra: Cloud browser uses a "zero client" as all STB functions are moved to the cloud. However, certain logics still needed in the STB so that screens can be overlaid
<bryan> Nilo, there could be options as to what types of functionality are supported by the user-side (home or mobile device), and where those functions are implemented (STB, user device, cloud-based client). We would need to drive those things as we get to a more common understanding of the concept and arch options.
<kaz> accessibility use cases
Kaz: Web & TV interest group also worked on accessibility uses cases
Colin was asked to explain his input
<yosuke> https://lists.w3.org/Archives/Public/public-web-and-tv/2016Jan/0005.html
<kaz> Colin's writeup above
<kaz> Colin's diagram
Colin showed a figure. To him, cloud browser is a regular browser living in the cloud environment
Cloud browser is responsible for all accessibility. Example, a keyboard requires all key strokes to be passed to the cloud browser
Out of band media from a PVR is fed to the local run time environment to "mix" with the control stream
John: As we cannot physically wire keyboard, is a companion screen used to connect with the cloud browser
Colin: You could also have the physical keyboard tap into the thin client run time environment
<bryan> Websockets could be a good mechanism for delivery of the signalling events to the cloud browser.
Colin: Several ways are possible to make cloud browser accessible. try to make it as normal as possible, so that the browser does not need to know it is running in the cloud. then most accessibility methods work
bryan: Out of band media means that ti can consume local resources. This needs support for several APIs which may not make this runtime environment "thin"
Colin: try and keep it as thin as possible
Kaz: can we add this figure to the wiki page?
Colin: This is just one of many possible solutions. However, leave it open. this can be a starting point
Alexandra: The group has to
define the gaps
... Via use cases.
Colin: The cloud environment sends the UI to the runtime via stream and some sort of signalling is needed for a session setup
<bryan> ... Probably a RESTful API accessed by the thin client and served by the cloud browser would be useful for session management.
Alexandra: Want to discuss in group with a general overview of the arch so that we can discuss the different approaches. The use cases need to take into account the interactions between the cloud browser and the local runtime environment
<bryan> Once a session was started, a websocket connection could be used for signalling and any non-video feedback to the thin client.
Colin: Assume that the stream is a video stream. Alongside a video stream you can also send images. The runtime environment can mix the stream with a series of images
Alexandra: Are these different
architectures?
... Where would be the media player be placed? Ina zero clinet,
the media player could also be in the cloud.
<bryan> The result of cloud-browser-based dialogs e.g. permissions or other dialogs, would need to be passed back down to the thin client if the client was intended to access local resources. The security of that would be a key consideration...
Colin: In a PVR, you don't send the video to the cloud and then send it back. therefore you need something in the client for out-of-band media.
Alexandra: We don't identify protocols; just the architecture. This will be done afterwards
Bryan: Talk about use cases and requiements, but don't document the architecture options in the use cases and requirements document
Alexandra: Discuss cloud 360 use case
Louay: They have a cloud server
which renders a video of just what was requested (e.g, a
particular angle)
... Don't stream the whole 360 degree view but just what was
requested. Existing JS libraries rendering 360 video need use
case to only send just what is requested
... IS this a good use case for the cloud browser?
Alexandra: Make up a couple of use cases and add to the Wiki
Louay: Will do so with more details/diagrams
Alexandra: Will add use cases for the cloud browser on how exisiting use cases work (PVR, interactivity, EPG etc.)
Louay: Want to make sure that their use cases are at the same level as those submitted by others. Their use cases are from an end user perspective, not a systems perspective.
Alexandra: His use case could be for virtual/augmented reality
<kaz> Use Case wiki
Alexandra: Summarizing the meeting.
Kaz: may wish to revisit the template for the use cases. need a motivation field and a Reviewer field
Ronen: We take HTML content that
runs in a cloud browser. We need to see ahat types of HTML5
content we have (e.g., EPG) and see what happens if this is not
run on a local browser.
... Need to look at OTT content, games etc. Each of these would
be a use case.
... Use cases would be on user interaction with these types of
applications where the browser is in the cloud - what gaps
exist?
Alexandra: Will discuss with
Ronen before putting such use cases on the Wiki
... Will also align it with other use cases such as EPG, HbbTV
etc.
No further questions or discussion. Meeting closed.
Continue discussions via email.