W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2016

RE: [Cloud Browser] Some comments on the Architecture chapter

From: <Alexandra.Mikityuk@telekom.de>
Date: Mon, 6 Jun 2016 19:06:50 +0200
To: <C.Meerveld@activevideo.com>, <nilo.mitra@ericsson.com>
CC: <public-web-and-tv@w3.org>
Message-ID: <DFCEF737B0F85B46B6CD03C6CEE84178E7468F1832@HE111642.emea1.cds.t-internal.com>
Dear Nilo, dear Colin

Thank you for your comments, it’s a very good work!
See my comments in blue. Please, take a look at the comment as I raise a couple of questions there.


Hi Nilo,


•        In the section on Terminology, what is the difference between the “TV UI zero client approach” and the “Cloud browser”? The description seems to be much the same, but perhaps there are subtle differences? If there isn’t, I’d keep one of these and add the other to the “Also known as” cell of the one retained .

In the terminology section the "TV UI zero client approach" is a a concept where we differentiate the approaches to bring TV UIs. The cloud browser is a single unit used in the TV UI zero client approach. It is comparable with any other browser only originated in the cloud.

I see the issue. I have read the descriptions again and I also see that they somehow sound very similar. I will combine the Colin’s comment and put some more clarity into the explanations. I have created an issue [1].


•        Also in the section on Terminology, Out-of-band media and In-band media are defined as the principal terms, with Double Stream Approach and Single Stream Approach, respectively, placed as secondary under “Also known as”. However, in later sections the terms out-of-band and in-band are not used and the double stream and single stream terms are used extensively. Thus, I would suggest that the placements be reversed and that double/single stream be the primary terms and the out-of-band/in-band be placed under “also known as”.

I believe they are not  interchangeable and therefore i would like to suggest to remove the ”Also Known as”. Maybe we should move the definitions under the section “Architecture” to the definitions.

Indeed, there was a mistake. I have removed the “Also Known As” and extended the definitions in the “Terminology” section by those available in the “Architecture” section. Thank you for suggestions!


•        Depending on the resolution of the above points, the section “Evolution of the TV UI” may need to be updated. It would be best if the same and principal term were used throughout rather than use every variant (in “also known as”) in different sentences. (The idea of having “also known as” seemed like a good one at the time, but it can be very confusing if the primary terms are not used consistently throughout the document.)

I fully agree that we should use the principal term on the wiki. We added the column to point to terminologies used out side of this TF.

OK. Is an action point for me. Indeed, this description is very old and needs to be revised. For this the action [2].

•        Finally, in Double Stream Local Player Approach Functions, I did not understand the sentence following the table “Cloud Environment functions notice: also the UI enryption in case of sensitive video elements might be applied. Here also the video decryption function might be required.” What is it trying to say?  Maybe these could be added to the table with the words “(if required)” or “(optional)”, as appropriate.

I am also not sure. I don’t think the cloud environment has to deal with encryption with the local player approach. To me the entire section is a bit hard to read. In essence it is quite simple. Either  the UI and media is combined or separated. If it is combined it is a single stream and the player is in the cloud (cloud player approach). if it is separated only the UI is generated in the cloud and the media is streamed from another source (out-of-band). The latter we called a double stream approach which needs a local player (hence local player approach). Conceptual, this is all there is.

The hard part is where we tried to mix those things. e.g. double stream with cloud player. i understand the rational behind this but believe we make it to complicated to be manageable. My suggestion would be to move those use cases to an note.

OK. A very interesting point. To reply to the initial question made by Nilo -->
What I meant was – if we have the in-band media, that needs to be protected, as part of the UI stream, also the UI encryption might be applied, than the Cloud Browser will also have to encrypt the UI stream. You are right that its optional so I will put it as “optional” into the table.

Colin has mentioned a very good point in his comment.
Do you think I have to highlight the two approaches that you, Colin, have mentioned in your explanation after “In essence it is quite simple”?
I could describe it in a way, that these approaches are used in the industry and the rest is hypothetically right, but is not really in use?
This way I could remove the description of the hypothetical approaches to a subsection (or to remove it completely) and focuse on the two approaches, that have passed the sanity check, so to say ☺

Regards,

Colin

[1] https://www.w3.org/2011/webtv/track/actions/245

[2] https://www.w3.org/2011/webtv/track/actions/246



Kind regards
Alexandra Mikityuk


Deutsche Telekom AG
T-Labs (Research & Innovation)
Alexandra Mikityuk
Winterfeldtstr. 21, 10781 Berlin
+4930835358151 (Phone)
+4930835358408 (Fax)
+491715669475 (Mobile)
E-Mail: alexandra.mikityuk@telekom.de
www.telekom.com<http://www.telekom.com/>

Life is for sharing.

You can find the obligatory information on www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement>

Big changes start small – conserve resources by not printing every e-mail.




Received on Monday, 6 June 2016 17:06:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 6 June 2016 17:06:40 UTC