<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

-> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Introduction_cloud_browser Colin's write-up

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!
... 2 comments
... 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 environment

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

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

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

-> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture main architecture wiki

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 approaches
... "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 HTML

alex: review for a few weeks

Session ID

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

-> https://lists.w3.org/Archives/Public/public-web-and-tv/2016Jul/0001.html session use case discussion

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 discussion

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 ]