See also: IRC log
<scribe> scribenick: kaz
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
-> 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!
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
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
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 ]