[Cloud Browser] Architecture updates/questions

Dear all,

working on the action points [1] to [5] with regard to updates of the Cloud Browser architecture, I have a couple of questions to the group.


1.      On the one side it would be sufficient to define a flexible architecture, where the functions are not hard-coded and are rather assigned on the fly depending on the approach.

However, as we have already defined 4 approaches and agreed that they would be enough for the moment to cover the Use Cases we have [6],
my 1st question would be, would it make sense to define a simple function set and describe which functions are supported by the server and which by the client for each of the
approaches?
Such a function set could look like:
Composition; execution; UI rendering; Video rendering; encoding/ decoding (hardware, software); scrambling/ descrambling (hardware, software); networking; session mgmt.; user input processing; transcoding.

By defining of these functions for each Approach, it would be more clear, which of these build the Runtime Environment of the Cloud Browser Client.
Some of these would be done only in hardware in case of the e.g. Single Stream Cloud Player


2.      The second question would be with regard to the description of these approaches. Would it make sense to describe it with following sections

·        Technical description

·        Considered devices

·        Operation scope (for which cases is used)

To make it more clear, I have made an exemplarily description of the Single Stream Cloud Player approach that you can find in the end of the E-Mail in [12].


3.      Would it be better to include the Media Player into the Runtime Environment - this way it would be more clear that the Media Player is a part of the Runtime Environment of the client.

I have also provided more clear arch pictures, inspired by the Initial Concept arch made by Colin. Please, see [7] to [10]. Do they provide a better description or are they too technical and it would be better to stay with the current once available in [11]?


[1] https://www.w3.org/2011/webtv/track/actions/215
[2] https://www.w3.org/2011/webtv/track/actions/220
[3] https://www.w3.org/2011/webtv/track/actions/221
[4] https://www.w3.org/2011/webtv/track/actions/225
[5] https://www.w3.org/2011/webtv/track/actions/227
[6] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases
[7] https://www.w3.org/2011/webtv/wiki/File:Ss-cp.png
[8] https://www.w3.org/2011/webtv/wiki/File:Ss-lp.png
[9] https://www.w3.org/2011/webtv/wiki/File:Ds-cp.png
[10] https://www.w3.org/2011/webtv/wiki/File:Ds-lp.png
[11] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture

[12] Description example:


Technical Description:

After the input data is downloaded, the CSS and HTML is parsed and interpreted by the Cloud Browser.

The JavaScript is processed and executed by the JavaScript engine of the browser.

After the DOM and the Render Trees are built, the painting commands are sent to the Graphics Library over the Graphics Context.

The video is downloaded from the Media Sources by the browser and is also sent to the Graphics Library of the CB server.

The Graphics Library renders and writes the data into the Buffer.

However, in the case of the Cloud Browser, the data is not sent to the display.

The data is encoded using a required video codec and sent as a video stream to the Cloud Browser client over IP.

For this delivery either HTTP or RFB application layer protocols could be used, depending on the implementation.

The CB client receives the input stream that is directly decoded by the Decoder.

The stream might be also first processed by the Descrambler, if the content is encrypted by the CB with an encryption scheme supported by the CB client.



Considered devices: legacy devices, low-end and low-power devices only with hardware functions.



Operation Scope:

In this approach the CB overtakes all CB client software functionalities.

The CB adapts the output data to the available hardware of the CB client, e.g. secure processor, video decoding, network.

Therefore, the client functions are limited to the available hardware.

The reduced Runtime Environment of the CB client is limited to support of these legacy hardware capabilities, if required.

It could contain specific video functions that could not be reduced, as quality probes for quality measurements.

This approach could be used e.g. for simplification of the client decryption.

The decryption functions are terminated in the Cloud and re-encrypted by sending the stream down to the client.

This Scenario implies decryption capabilities of the Cloud Environment.

The client doesn't need to support the source encryption.



Mit freundlichen Grüßen / Viele Grüße / Best Regards
Alexandra Mikityuk


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

Erleben, was verbindet.

Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.com/pflichtangaben<http://www.telekom.com/pflichtangaben>

Grosse Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.