IRC log of webtv on 2016-07-06

Timestamps are in UTC.

13:03:11 [RRSAgent]
RRSAgent has joined #webtv
13:03:11 [RRSAgent]
logging to
13:03:21 [kaz]
present: Kaz, Alexandra, Nilo, Steve
13:04:14 [colin]
colin has joined #webtv
13:05:01 [Nilo]
Nilo has joined #webtv
13:05:41 [kaz]
present+ Colin
13:06:58 [kaz]
zakim, pick a scribe
13:06:58 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Nilo
13:07:04 [kaz]
zakim, pick a scribe
13:07:04 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Steve
13:07:23 [kaz]
zakim, pick a scribe
13:07:23 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Colin
13:07:47 [kaz]
zakim, pick myself :)
13:07:47 [Zakim]
I'm glad that smiley is there, kaz
13:07:56 [kaz]
scribenick: kaz
13:08:43 [kaz]
alex: great that ActiveVideo has joined W3C :)
13:09:42 [kaz]
13:10:02 [kaz]
alex: Colin made great job for the draft document
13:10:14 [kaz]
... will share the screen
13:11:25 [kaz]
colin: created a separate page
13:11:57 [kaz]
... will go to the page and introduce it
13:12:43 [kaz]
-> Colin's write-up
13:14:17 [kaz]
colin: short introduction about what "Cloud Browser" is like
13:14:52 [kaz]
... the first diagram shows a "Local browser"
13:15:05 [kaz]
... and the second one shows a "Cloud browser"
13:15:34 [kaz]
s/second/second one and the following ones/
13:17:14 [kaz]
... "orchestration" responsible for communication between the client and cloud browser, etc.
13:17:23 [kaz]
nilo: need to define "orchestration"
13:17:49 [kaz]
colin: ok, we should update the main architecture document with the definition
13:18:55 [kaz]
... "rte" (Runtime Environment)
13:19:02 [kaz]
... Each client need to implement a small part which should be standardized to be vendor interchangeable
13:19:24 [kaz]
... identifying the gaps with the existing standards
13:20:03 [kaz]
... important to identify who uses resources
13:20:41 [kaz]
... 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.
13:20:49 [alexandra-mikityuk]
13:20:52 [kaz]
13:21:08 [kaz]
nilo: very nice
13:21:43 [kaz]
... maybe you might want to expand the sentence saying "This is not the only task"
13:21:48 [kaz]
colin: right
13:21:55 [kaz]
... still generating the text
13:22:03 [kaz]
... and would like to improve it
13:22:16 [kaz]
... also want to edit the last block
13:22:27 [kaz]
alex: tx, Colin!
13:22:30 [kaz]
13:22:45 [kaz]
... wanted to ask about the display example
13:22:58 [kaz]
... do you also address display as a client?
13:23:09 [kaz]
colin: have to add communication use case
13:23:41 [kaz]
alex: another one is
13:23:46 [kaz]
... a bit confused
13:24:05 [kaz]
... we wanted to establish standard APIs
13:24:36 [kaz]
... address browser vendors are expected to implement the API
13:25:09 [kaz]
... who has implementation?
13:25:22 [kaz]
... implemented by the browser itself
13:25:27 [kaz]
... or by the environment
13:25:43 [kaz]
... we should clarify that
13:25:47 [kaz]
colin: good question
13:26:17 [kaz]
... cloud browser without any change can use the API
13:26:50 [kaz]
... compatible API or vendor specific one
13:27:17 [kaz]
... sometimes communication between orchestration and environment
13:27:46 [kaz]
alex: three logical groups
13:28:26 [kaz]
... rte, gaps towards JS api, and implementation by Google/Microsof, etc.
13:28:45 [kaz]
... we have risk people won't implement our APis
13:29:11 [kaz]
... possibly implemented by Google/Mozilla
13:29:36 [kaz]
colin: cloud browser api?
13:29:57 [kaz]
alex: maybe there are something executed by the browser itself
13:30:08 [kaz]
colin: rte is something simple here
13:30:38 [kaz]
... cloud browser could be different from Android OS
13:31:39 [kaz]
alex: is the JS logic part of browser?
13:31:45 [kaz]
... or rte?
13:32:11 [kaz]
colin: API should be part of the cloud browser
13:32:23 [kaz]
... but should not be a specific cloud browser api
13:32:58 [kaz]
alex: MSE, EME or TV Control API, etc.
13:33:42 [kaz]
nilo: most compelling part is that application shouldn't change
13:34:38 [kaz]
... don't have to care about whether local or not
13:35:42 [kaz]
colin: we're able to do that
13:36:17 [kaz]
alex: requirements for cloud browser
13:36:36 [kaz]
s/requirements/maybe could put as requirements/
13:37:10 [kaz]
colin: maybe we could have use cases which don't depend on the mechanism (local or not)
13:37:16 [kaz]
alex: ok
13:37:30 [kaz]
... and you could expand the text as well
13:38:08 [kaz]
... we'll work with existing groups to see gaps
13:38:29 [kaz]
nilo: clarification question
13:39:14 [kaz]
colin: hoped to explain much more in the architecture section
13:39:25 [kaz]
... but started this separate article
13:39:37 [kaz]
13:39:44 [alexandra-mikityuk]
13:41:35 [kaz]
kaz: @@@
13:41:46 [kaz]
... what is done on which side
13:42:00 [kaz]
... and data transfer, etc., should be clarified
13:42:04 [kaz]
colin: good question
13:42:22 [kaz]
... orchestration deals with abstraction
13:42:37 [kaz]
... tuner api also is abstracted by orchestration
13:43:01 [kaz]
... we could implement tuner api
13:43:10 [kaz]
... and cloud browser could use that
13:43:28 [kaz]
... but how orchestration would do is fairly complicated
13:44:56 [kaz]
kaz: "orchestration" sounds similar to UI integration, i.e., multimodal interaction
13:45:05 [kaz]
colin: would see that spec as well
13:45:38 [kaz]
-> multimodal interaction charter
13:46:20 [kaz]
kaz: maybe state transition capability would be useful for cloud browser too
13:46:24 [kaz]
colin: should look at that
13:46:48 [alexandra-mikityuk]
13:46:56 [kaz]
ack k
13:47:06 [kaz]
alex: tx a lot, Colin
13:47:22 [kaz]
... would be great if you could add a link from the main architecture page to this introduction wiki
13:47:24 [kaz]
colin: ok
13:47:47 [kaz]
alex: shaping the scope is great
13:48:23 [kaz]
... if we're ok with this, have another question on the architecture doc
13:50:00 [kaz]
topic: Main Architecture wiki
13:50:22 [kaz]
-> main architecture wiki
13:50:26 [kaz]
alex: we have 4 models
13:51:02 [kaz]
... we have "primary approaches" and "secondary approaches"
13:51:21 [kaz]
... and have "Cloud Browser Lifecycle"
13:51:57 [kaz]
... and "Terminology"
13:52:09 [kaz]
... and then "Evolution of the TV UI"
13:52:24 [kaz]
... and "Architecture" section after that
13:53:12 [kaz]
... sometimes to use cloud browsers
13:53:27 [kaz]
... in that case we use local browser
13:54:28 [kaz]
... diagrams of main/primary approaches and secondary approaches
13:54:37 [kaz]
... "Functions" section
13:54:48 [kaz]
... comments welcome
13:54:59 [kaz]
... good description we would address
13:55:07 [kaz]
colin: much more clear now
13:55:12 [kaz]
... good improvement
13:55:31 [kaz]
alex: tx!
13:56:47 [kaz]
... the TF Charter wiki says the deadline is 23 Sep.
13:58:00 [kaz]
kaz: we can extend the TF period :)
13:58:14 [kaz]
... we can send an announcement/proposal to the IG list
13:58:20 [kaz]
alex: ok
13:58:55 [kaz]
kaz: we can publish this architecture wiki after converting to HTML
13:59:09 [kaz]
alex: review for a few weeks
14:00:33 [kaz]
... we need to handle the session use cases as well
14:00:47 [kaz]
-> session use case discussion
14:01:20 [kaz]
alex: what is your view on session handling
14:01:24 [kaz]
14:01:41 [kaz]
... who would handle/establish sessions?
14:01:54 [kaz]
colin: could be both
14:02:09 [kaz]
... orchestration also called as session manager
14:02:48 [kaz]
alex: is it valid to use session id?
14:02:57 [kaz]
colin: yes
14:03:36 [kaz]
alex: in some case, the application has complete capability to handle sesson
14:04:05 [kaz]
colin: has just read this message
14:04:16 [kaz]
... client sets up the connection
14:04:50 [kaz]
alex: if we destroy the session, every entity in the framework could destroy it?
14:05:05 [kaz]
... or only the guy who created can destroy?
14:05:12 [kaz]
colin: both should be possible
14:06:12 [kaz]
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
14:07:07 [kaz]
alex: before writing the concrete use cases, would be good to have description on every entity within the architecture
14:07:22 [kaz]
... who could destroy whom
14:07:38 [kaz]
... if you have any opinions, please respond to the email
14:07:45 [alexandra-mikityuk]
14:07:58 [kaz]
colin: question regarding TPAC
14:08:05 [kaz]
... never joined TPAC sessions
14:08:14 [kaz]
... most of us are going to TPAC?
14:08:17 [kaz]
alex: yes
14:08:48 [kaz]
... as a part of the main Web&TV IG, we'll get a session during the f2f
14:09:04 [kaz]
... TF update, etc.
14:09:13 [kaz]
... have already contacted the Chairs
14:09:33 [Nilo]
what are the dates of the TPAC?
14:09:42 [kaz]
... would have a specific session for cloud browser discussion
14:10:22 [kaz]
kaz: TPAC will be held Sep. 19-23
14:11:37 [kaz]
alex: can extend the meeting schedule?
14:11:42 [kaz]
kaz: need to pay more
14:11:54 [kaz]
... but we can use Wednesday for additional discussion
14:12:06 [kaz]
... using the breakout meeting
14:12:33 [kaz]
kaz: will remind the IG co-Chairs of the TPAC schedule
14:12:39 [kaz]
alex: ok
14:12:48 [kaz]
... please review the architecture wiki
14:13:00 [kaz]
... also look at the use case document as well
14:13:10 [kaz]
... the next meeting will be held in 2 weeks
14:13:17 [Nilo]
ok, bye
14:13:40 [kaz]
[ adjourned ]
14:15:16 [kaz]
rrsagent, make log public
14:15:22 [kaz]
rrsagent, draft minutes
14:15:22 [RRSAgent]
I have made the request to generate kaz
14:18:03 [kaz]
Meeting: Web and TV IG - Cloud Browser TF
14:18:10 [kaz]
Chair: Alexandra
14:18:33 [kaz]
i/great that/topic: Architecture introduction/
14:18:36 [kaz]
rrsagent, draft minutes
14:18:36 [RRSAgent]
I have made the request to generate kaz
14:19:46 [kaz]
s/@@@/TV Control API could be used on the Cloud Browser side/
14:20:07 [kaz]
s/what is done on which side/need to clarify what is done on which side/
14:20:25 [kaz]
rrsagent, draft minutes
14:20:25 [RRSAgent]
I have made the request to generate kaz