W3C home > Mailing lists > Public > public-web-and-tv@w3.org > July 2016

Re: [cloud browser] minutes - 6 July 2016

From: Meerveld, Colin <C.Meerveld@activevideo.com>
Date: Fri, 15 Jul 2016 12:23:10 +0000
To: Kazuyuki Ashimura <ashimura@w3.org>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <532D8D02-D94A-4AD2-A61E-F4A4018E3093@activevideo.com>
Hi Kaz,

I looked into the Multimodel Interaction Working Group [1] as you suggested. I agree that the orchestration is quite similar to the so-called Interaction Manager [2]. Though as far as i understand there are some fundamental differences. An interaction manager doesn't have a single source. In our architecture it would mean that the rte has a interaction manager as well. IMO the rte should be as bare-bone as possible and shouldn't provide any semantics to the data. this is in contrast with the mmi where providing semantics seems to be the main goal. Still it is a valuable source but not sure how it will fit into the cloud browser. I would encourage other members to look into this working group as-well.

I made some changes in the cloud browser introduction [3] to make this bare-bone rte idea more explicite as it should be one of the principle concepts in the cloud browser. btw i also added a link in the cloud browser main page [4] to the introduction.



[1] http://www.w3.org/2002/mmi/
[2] http://www.w3.org/TR/2012/REC-mmi-arch-20121025/#d3e386
[3] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Introduction_cloud_browser
[4] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF

On 06 Jul 2016, at 20:26, Kazuyuki Ashimura <ashimura@w3.org<mailto:ashimura@w3.org>> wrote:

available at:

also as text below.

The next call will be held on July 20th.




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

                               - DRAFT -

                    Web and TV IG - Cloud Browser TF

06 Jul 2016


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

   See also: [3]IRC log

      [3] http://www.w3.org/2016/07/06-webtv-irc


          Kaz, Alexandra, Nilo, Steve, Colin




     * [4]Topics
         1. [5]Architecture introduction
         2. [6]Main Architecture wiki
         3. [7]TF period
         4. [8]Session ID
         5. [9]TPAC schedule
     * [10]Summary of Action Items
     * [11]Summary of Resolutions

   <scribe> scribenick: kaz

Architecture introduction

   alex: great that ActiveVideo has joined W3C :)
   ... Colin made great job for the draft document
   ... will share the screen

   colin: created a separate page
   ... will go to the page and introduce it

   TF/Introduction_cloud_browser Colin's write-up

     [12] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Introduction_cloud_browser

   colin: short introduction about what "Cloud Browser" is like
   ... the first diagram shows a "Local browser"
   ... and the second one and the following ones one shows a
   "Cloud browser"
   ... "orchestration" responsible for communication between the
   client and cloud browser, etc.

   nilo: need to define "orchestration"

   colin: ok, we should update the main architecture document with
   the definition
   ... "rte" (Runtime Environment)
   ... Each client need to implement a small part which should be
   standardized to be vendor interchangeable
   ... identifying the gaps with the existing standards
   ... important to identify who uses resources
   ... For example, in the case of EME, this could be a problem
   because the media is send in the clear from the orchestration
   to the rte.

   nilo: very nice
   ... maybe you might want to expand the sentence saying "This is
   not the only task"

   colin: right
   ... still generating the text
   ... and would like to improve it
   ... also want to edit the last block

   alex: tx, Colin!
   ... wanted to ask about the display example
   ... do you also address display as a client?

   colin: have to add communication use case

   alex: another one is
   ... a bit confused
   ... we wanted to establish standard APIs
   ... address browser vendors are expected to implement the API
   ... who has implementation?
   ... implemented by the browser itself
   ... or by the environment
   ... we should clarify that

   colin: good question
   ... cloud browser without any change can use the API
   ... compatible API or vendor specific one
   ... sometimes communication between orchestration and

   alex: three logical groups
   ... rte, gaps towards JS api, and implementation by
   Google/Microsof, etc.
   ... we have risk people won't implement our APis
   ... possibly implemented by Google/Mozilla

   colin: cloud browser api?

   alex: maybe there are something executed by the browser itself

   colin: rte is something simple here
   ... cloud browser could be different from Android OS

   alex: is the JS logic part of browser?
   ... or rte?

   colin: API should be part of the cloud browser
   ... but should not be a specific cloud browser api

   alex: MSE, EME or TV Control API, etc.

   nilo: most compelling part is that application shouldn't change
   ... don't have to care about whether local or not

   colin: we're able to do that

   alex: maybe could put as requirements for cloud browser

   colin: maybe we could have use cases which don't depend on the
   mechanism (local or not)

   alex: ok
   ... and you could expand the text as well
   ... we'll work with existing groups to see gaps

   nilo: clarification question

   colin: hoped to explain much more in the architecture section
   ... but started this separate article

   kaz: TV Control API could be used on the Cloud Browser side
   ... need to clarify what is done on which side
   ... and data transfer, etc., should be clarified

   colin: good question
   ... orchestration deals with abstraction
   ... tuner api also is abstracted by orchestration
   ... we could implement tuner api
   ... and cloud browser could use that
   ... but how orchestration would do is fairly complicated

   kaz: "orchestration" sounds similar to UI integration, i.e.,
   multimodal interaction

   colin: would see that spec as well

   -> [13]https://www.w3.org/2013/10/mmi-charter.html multimodal
   interaction charter

     [13] https://www.w3.org/2013/10/mmi-charter.html

   kaz: maybe state transition capability would be useful for
   cloud browser too

   colin: should look at that

   alex: tx a lot, Colin
   ... would be great if you could add a link from the main
   architecture page to this introduction wiki

   colin: ok

   alex: shaping the scope is great
   ... if we're ok with this, have another question on the
   architecture doc

Main Architecture wiki

   TF/Architecture main architecture wiki

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

   alex: we have 4 models
   ... we have "primary approaches" and "secondary approaches"
   ... and have "Cloud Browser Lifecycle"
   ... and "Terminology"
   ... and then "Evolution of the TV UI"
   ... and "Architecture" section after that
   ... sometimes to use cloud browsers
   ... in that case we use local browser
   ... diagrams of main/primary approaches and secondary
   ... "Functions" section
   ... comments welcome
   ... good description we would address

   colin: much more clear now
   ... good improvement

   alex: tx!

TF period

   alex: the TF Charter wiki says the deadline is 23 Sep.

   kaz: we can extend the TF period :)
   ... we can send an announcement/proposal to the IG list

   alex: ok

   kaz: we can publish this architecture wiki after converting to

   alex: review for a few weeks

Session ID

   alex: we need to handle the session use cases as well

   Jul/0001.html session use case discussion

     [15] https://lists.w3.org/Archives/Public/public-web-and-tv/2016Jul/0001.html

   alex: what is your view on session handling?
   ... who would handle/establish sessions?

   colin: could be both
   ... orchestration also called as session manager

   alex: is it valid to use session id?

   colin: yes

   alex: in some case, the application has complete capability to
   handle sesson

   colin: has just read this message
   ... client sets up the connection

   alex: if we destroy the session, every entity in the framework
   could destroy it?
   ... or only the guy who created can destroy?

   colin: both should be possible

   kaz: in that case the guy (who didn't create the session but
   would destroy the session) need to get the session id and
   permission to destroy the session

   alex: before writing the concrete use cases, would be good to
   have description on every entity within the architecture
   ... who could destroy whom
   ... if you have any opinions, please respond to the email

TPAC schedule

   colin: question regarding TPAC
   ... never joined TPAC sessions
   ... most of us are going to TPAC?

   alex: yes
   ... as a part of the main Web&TV IG, we'll get a session during
   the f2f
   ... TF update, etc.
   ... have already contacted the Chairs

   <Nilo> what are the dates of the TPAC?

   alex: would have a specific session for cloud browser

   kaz: TPAC will be held Sep. 19-23

   alex: can extend the meeting schedule?

   kaz: need to pay more
   ... but we can use Wednesday for additional discussion
   ... using the breakout meeting
   ... will remind the IG co-Chairs of the TPAC schedule

   alex: ok
   ... please review the architecture wiki
   ... also look at the use case document as well
   ... the next meeting will be held in 2 weeks

   <Nilo> ok, bye

   [ adjourned ]

Summary of Action Items

Summary of Resolutions

   [End of minutes]

    Minutes formatted by David Booth's [16]scribe.perl version
    1.144 ([17]CVS log)
    $Date: 2016/07/06 14:26:15 $

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

Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504

Received on Friday, 15 July 2016 12:23:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:31 UTC