[Cloud Browser] minutes - 25 May 2016

available at:
  https://www.w3.org/2016/05/25-webtv-minutes.html

also as text below.

Thanks a lot for taking these minutes, Nilo!

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                      Web&TV IG - Cloud Browser TF

25 May 2016

   [2]Agenda

      [2]
https://lists.w3.org/Archives/Member/member-web-and-tv/2016May/0000.html

Attendees

   Present
          Kaz_Ashimura, Alexandra_Mikityuk, Colin_Meerveld,
          Harrison_Yun, Nilo_Mitra, Bill_Rose

   Regrets
   Chair
          Alexandra

   Scribe
          NiloMitra

Contents

     * [3]Architecture
     * [4]Use Cases
     * [5]Summary of Action Items
     __________________________________________________________

   Nilo is the scribe

Architecture

   ->[6]Architecture wiki

      [6]
https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture

   Close to completing work on the architecture. Thus the chapter
   can be considered mainly complete, and freeze it.

   Alexandra will finalize the chapter and send it to the group
   for review.

   Alexandra provided an overview of the architecture chapter.

   <scribe> New section on functions added last week.

   Agreed that it would be good to have everyone review the
   chapter and correct the minor errors that may be detected.

   Harrison has some input to be provided on lifecycle.

   Yosuke also wanted some explanation on changes (if any) the DOM
   tree. It is not changed. This will be added.

   Everyone is asked to go though the functions and make updates
   as necessary. After two weeks this chapter will be sent out for
   final review.

Use Cases

   [7]Use Case wiki

      [7]
https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases

   Now we move to the use cases chapter.

   Alexandra asked if, given the architecture chapter, the use
   case author could identify with which architecture the use case
   could apply?

   Colin said that this could be provided in the Notes.

   Alexandra noted that we have to provide the requirements
   document by autumn.

   She used the example of the home networking requirements
   document to show how that document added requirements into the
   use cases.

   She suggest that we also try an describe the requirements
   implied by each use case

   coiln was asked to convert his submitted use case on tuners
   into the template provided

   Alexandra proposes adding a separate Wiki page on requirements.

   Kaz agrees and suggests adding a link from the requirements to
   the use cases. later this can be published as an IG Note
   (HTML).

   s.suggests/suggests

   Colin was asked to send a link to the tuner use case to the
   list

   Colin described the use case. the requirement is that the cloud
   environment must be able to signal to the client to tune to a
   channel.

   <kaz> [8]Tuner use case wiki

      [8]
https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/Tuner

   alexandra: should cloud browser be able to get the tuner state
   of the client?

   alexandra: it is good to reference tv control api, but it would
   be good to abstract it

   colin agrees that it could be any api that provides the
   necessary feature

   colin provided a more detailed explanation of step 1. on a
   local browser you retrieve the tuning information from the
   middleware by attaching to the multicast stream). in a cloud
   browser solution you don't receive the multicast stream. thus,
   you need to get the information (by another way. this is called
   the backend system in the use case.

   colin: asks harrison if this is how they do the translation.
   harrison thinks it is reasonable. however, he has a question
   about the tv control api. is this the one being standardized?
   answer is yes.

   harrison: overall description is reasonable. however, the
   environment must be prepared to support this scenario. EPG
   information is derived from the SI. This requires the
   preparation of a backoffice system which retrieves the SI
   information

   colin: even if we standardize the cloud browser solution, how
   the interaction with the backoffice takes place will remain
   proprietary

   alexandra: put harrison's point in the description

   colin: yes, the tuner use case exposes the various points where
   there would need to be proprietary interfaces

   alexandra: add a user?

   colin: that would make the use case more complicated
   ... this use case makes the application do the work, using the
   tv control api to tune to a channel. the only difference with
   the local browser case is that the cloud browser has to signal
   the client to do the tuning

   alexandra: explain what application means - the application
   which runs on the cloud browser server, for example
   ... add the requirements implied by the use case

   colin will update based on comments and using the template

   kaz: would it makes sense to add two sections - one for the
   basic architecture and one for concrete implementations?

   alexandra says that the uc sections will identify which
   architectures these apply to.

   kaz asks colin to add some more modules (e.g., tuner module) to
   the architecture

   kaz says it would be good to know where the tuner capability
   and the epg capability exists and will be handled

   alexandra asks if there are any additional issues/ None
   identified. She adjourns the meeting.

   [ adjourned ]

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [9]scribe.perl version
    1.128 ([10]CVS log)
    $Date: 2016/05/25 14:28:38 $

      [9] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [10] http://dev.w3.org/cvsweb/2002/scribe/