See also: IRC log
<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 ]