<scribe> scribenick: alexandra_mikityuk

open question for Alexandra is where our API actually resides

Should we follow the EME approach so that the application has a control over application

TF: we have to identify the missing specs on w3c to make an application run as on a normal browser

RTE could be also the Cloud Browser

colin... RTE could be a browser which impliments the CB API to talk to the Cloud Orchestration environemnt

<alexandra_mikityuk> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases

We will go through State and Control UCs

<scribe> scribenick: kaz

<alexandra_mikityuk> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/state

am: looking at the "state" use case

-> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/state state use case

am: this is direct continuation of the control use case
... two use cases

cm: brining events

am: in the first use case
... application runs on the cloud side
... and a lot of information on the client side as well
... we'll support different information
... resolution, color space, etc.
... requested by orchestration
... there must be a control channel
... requested state must be available
... must be made available by the orchestration

cm: important part of the use case
... more details of the use case

am: we should clarify which is the basic functionality and which is additional one
... US-State-2
... Description: An event made it necessary to signal the Cloud Browser that the current state has changed

cm: if the client has sensory data
... every 20ms, etc.
... better approach would be cloud browser telling some particular event and the client send back another event

am: ok
... there are lot of events
... like key presses, remote control stops the video...
... device plugged/unplugged

cm: yes

am: session of use cases

cm: good approach

am: one cloud browser and one RTE

cm: state and control
... we could use reference to explain the use cases

am: control, state, session
... synchronization of building apis
... we're closing the session use cases
... would talk with other groups
... Web Crypto, TV Control, etc.
... you've partially addressed your tuner use cases
... high-level description on the gaps

cm: TV Control API especially tuner API
... don't see any issues with that

am: the idea is that TV Control API also have listener?
... very general work
... which part could be reused?
... better approach to copy the use cases
... interesting for the Cloud Browser TF

cm: if the idea is general browser, e.g., in smart tv, it should work

am: good to mention the tuner API if it works within the cloud browser context

cm: we already have one use case necessary in that area

am: that's true
... it's more of a summary
... what we're doing is how different from the other groups' work

cm: ok

am: next three weeks, you'll be not available?

cm: no, I'll be on holiday

am: planning for the TPAC meeting?

ka: will talk with the Web&TV IG Chairs again
... there will be the Web&TV IG f2f meeting on Monday
... the TV Control WG will be Tuesday
... FYI, we might want to look at DOM Events

-> https://www.w3.org/TR/DOM-Level-3-Events/ DOM Events L3

cm: I'm not familiar with this :)

ka: TV remote key codes can be handled this event model

cm: also checked the MMI Architecture

ka: that is an abstract level event handling model

-> https://www.w3.org/TR/mmi-arch/ MMI Architecture

cm: how to handle back key, etc., is interesting

ka: MMI Architecture was invented to integrate various UI modalities originally
... but could be used to integrate any kind of services

am: let's go through it (later)
... have some trouble with email system
... we'll have our next call in 2 weeks

[ adjourend ]