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

 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 ☺

Alexandra, i think we shouldn't remove it completely. In fact all combinations are used in the industry :-) Maybe it is hard to read because we try to explain everything. This is the mental modal i have:

A solution is either combined or separated.
- Combines means that both the media and ui is send from the same origin (The cloud browser). An implementation detail could be that the ui is not mix with the media but send as individual images.
- Separate means that the ui is send from the cloud browser but the media is out-of-band (i.e. another origin). An implementation detail is that the media control (start/stop/etc) could be handled by the cloud browser

To translate this to our terminology:
- The first one will be a single stream with a cloud player and the implementation detail would be a single stream with a local player
- the second would be a double stream with a local player and as implementation detail a double stream with a cloud player.

Currently all approaches are on the same level which is (for me at-least) hard to read. It would be helpful perhaps as we properly explain the single stream with cloud player and double stream with local player first and mention the alternatives below. In that way you don’t have to cope with all the different approaches directly but progressively learn while you read the architecture. i am happy to volunteer, taking this action.

Colin