Nilo is the scribe
Close to completing work on the architecture. Thus the chapter can be considered mainly complete, and freeze it.
Alexandra will finalize the chapter and send it to the group for review.
Alexandra provided an overview of the architecture chapter.
<scribe> New section on functions added last week.
Agreed that it would be good to have everyone review the chapter and correct the minor errors that may be detected.
Harrison has some input to be provided on lifecycle.
Yosuke also wanted some explanation on changes (if any) the DOM tree. It is not changed. This will be added.
Everyone is asked to go though the functions and make updates as necessary. After two weeks this chapter will be sent out for final review.
Now we move to the use cases chapter.
Alexandra asked if, given the architecture chapter, the use case author could identify with which architecture the use case could apply?
Colin said that this could be provided in the Notes.
Alexandra noted that we have to provide the requirements document by autumn.
She used the example of the home networking requirements document to show how that document added requirements into the use cases.
She suggest that we also try an describe the requirements implied by each use case
coiln was asked to convert his submitted use case on tuners into the template provided
Alexandra proposes adding a separate Wiki page on requirements.
Kaz agrees and suggests adding a link from the requirements to the use cases. later this can be published as an IG Note (HTML).
Colin was asked to send a link to the tuner use case to the list
Colin described the use case. the requirement is that the cloud environment must be able to signal to the client to tune to a channel.
<kaz> Tuner use case wiki
alexandra: should cloud browser be able to get the tuner state of the client?
alexandra: it is good to reference tv control api, but it would be good to abstract it
colin agrees that it could be any api that provides the necessary feature
colin provided a more detailed explanation of step 1. on a local browser you retrieve the tuning information from the middleware by attaching to the multicast stream). in a cloud browser solution you don't receive the multicast stream. thus, you need to get the information (by another way. this is called the backend system in the use case.
colin: asks harrison if this is how they do the translation. harrison thinks it is reasonable. however, he has a question about the tv control api. is this the one being standardized? answer is yes.
harrison: overall description is reasonable. however, the environment must be prepared to support this scenario. EPG information is derived from the SI. This requires the preparation of a backoffice system which retrieves the SI information
colin: even if we standardize the cloud browser solution, how the interaction with the backoffice takes place will remain proprietary
alexandra: put harrison's point in the description
colin: yes, the tuner use case exposes the various points where there would need to be proprietary interfaces
alexandra: add a user?
colin: that would make the use case
more complicated
... this use case makes the application do the work, using the tv
control api to tune to a channel. the only difference with the
local browser case is that the cloud browser has to signal the
client to do the tuning
alexandra: explain what application
means - the application which runs on the cloud browser server, for
example
... add the requirements implied by the use case
colin will update based on comments and using the template
kaz: would it makes sense to add two sections - one for the basic architecture and one for concrete implementations?
alexandra says that the uc sections will identify which architectures these apply to.
kaz asks colin to add some more modules (e.g., tuner module) to the architecture
kaz says it would be good to know where the tuner capability and the epg capability exists and will be handled
alexandra asks if there are any additional issues/ None identified. She adjourns the meeting.
[ adjourned ]