Re: [cloud browser] Review comments on architecture chapter.

Hi Steve,

Yes, i fully agree. At Activevideo we use the term "Nano Client" which is explained as an ultra thin client [1][2]. Perhaps we could use a definition like this. i.e. an ultra-thin client. Note that this ultra-thin client could be part of a thin client (as we defined in this TF. e.g. a javascript library act as a client within the local browser) which could cause some ambiguity. Anyhow we should refine the definition as you mentioned.

Thanks,

Colin

[1] http://www.activevideo.com/cloudtv
[2] http://www.activevideo.com/videos?id=80<http://www.activevideo.com/cloudtv>

On 26 Aug 2016, at 10:22, Steven Morris <smorris@Espial.com<mailto:smorris@Espial.com>> wrote:

Hi Colin,

I think the issue is that it’s not “zero client” in the strictest sense because the runtime environment is the client – it’s “zero client” in the sense of there not being a traditional middleware client or browser.  I agree that if we do use the term “cloud browser client” more widely then that we need to refine the definition of “zero client” that we’re using in order to clarify this.

Regards,
Steve.

From: Meerveld, Colin [mailto:C.Meerveld@activevideo.com]
Sent: 26 August 2016 09:19
To: Steven Morris
Cc: Ronen Mizrahi; Nilo Mitra; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: Re: [cloud browser] Review comments on architecture chapter.

I believe i coined the word "run time environment” as a lack of imagination on the time of writing and has evolved over time. I had chose this term to make a clear deviation from a client device. We could use the term “Cloud browser client” instead but should make sure that it is something different than the client device. Also the term 'zero client’ will contradict if we refer to a cloud browser client.

Colin


On 26 Aug 2016, at 10:10, Steven Morris <smorris@Espial.com<mailto:smorris@Espial.com>> wrote:

I’m happy to make these edits if everyone is happy with them, but it will be late next week before I’m able to do so.

Regards,
Steve.

From: Ronen Mizrahi [mailto:ronen@tversity.com]
Sent: 25 August 2016 18:04
To: Nilo Mitra
Cc: Steven Morris; public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: Re: [cloud browser] Review comments on architecture chapter.

I agree Nilo, I like it better too. It's definitely a lot clearer for a new reader.

On Aug 25, 2016, at 5:41 PM, Nilo Mitra <nilo.mitra@ericsson.com<mailto:nilo.mitra@ericsson.com>> wrote:
I particularly like Steve’s proposal to use “Cloud browser client” rather than “run time environment” throughout. The latter term is used in so many different contexts that it is likely to lead to confusion with existing usage and  also generate all sorts of incorrect mental associations.

Thanks,
Nilo

From: Steven Morris [mailto:smorris@Espial.com]
Sent: Thursday, August 25, 2016 6:11 AM
To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: [cloud browser] Review comments on architecture chapter.

Hi Alexandra, all,

Having reviewed the architecture page, I have a few comments on the contents.  Most of these are editorial, not technical, but they probably need wider discussion.


Terminology:
-        We use the terms “cloud browser client”, “runtime environment” and “RTE” through the document to mean the same thing.  In our terminology section, we use the term “runtime environment” as the preferred term, with “Cloud Browser Client” in the “also known as” column.  Given that “Runtime environment” is a generic term, it would probably be better to use the term “Cloud Browser Client” as our preferred term throughout the document.  This would then also be consistent with the other terms we use.
-        We use the abbreviation “CB” in many places to refer to the cloud browser.  It would be clearer if we always used the full term “Cloud Browser”.
-        I would suggest adding the following text to the end of the definition of “TV UI thin client approach”:
“… where most data (e.g. channel lists and EPG data) is provided by a remote server rather than being processed by the local software stack”
                This is to distinguish a true “thin” client from a full TV middleware stack that uses HTML for rendering the UI.

Evolution of the UI:
-        The first two sections appear to be very closely related to me.  I would suggest merging them and using the heading “TV local UI” to match the terminology definition.
-        I’m not sure the heading “Cloud Browser API” is necessary – it reads to me as if this is the next step in the evolution.  I would suggest removing the heading and merging this with the previous section.

Architecture section:
-        When talking about the different approaches to UI and video delivery, I’m not sure the term “graphics library” is the best term to describe the component that processes video.  I would suggest using “media processing function” instead, and rewording the paragraph after the description of the double stream approach as follows:  “Each of these sub-approaches can also be designed differently with regard to the location of the component that processes the media stream (Notice: in both these approaches the UI is processed in the Cloud Browser.). These divides the Zero Client Approach into two execution modes:”
-        We use the term “video” in several places to talk about what is delivered from the media sources.  This could include audio-only content as well (e.g. radio channels) and so it may be better to use “media” or “audio and/or video” instead.


Regards,
Steve.