Main Page/Cloud Browser TF/cloud browser vs split browser

A very related concept to the Cloud Browser is called a Split Browser. This article will explain the differences between them.

Same Problem

Both solutions try to solve the same problem: providing the end user with the best representation for their device. Before going into details we get started with traditional solutions.

Content Negotiation

Probably the most well know solution is content negotiation. The browser will let the origin server know which content it accepts. Based on those arguments the origin server will provide the best representation.

The World Wide Web differentiates between a resource and representation. The browser asks a resource whereas the origin server will decide which representation is sent back. An example could be that the resource is provided in a specific language or media type for a smartphone. In the sequence diagram you see this interaction.

Redirect

A redirect is very similar to content negotiation but instead of providing the correct representation for the same resource it will redirect the browser to another resource.

Responsive design

Another approach is to let the web application decide which representation is needed for a resource (e.g. a specific stylesheet for TV). The browser interprets this and requests the correct resource (e.g. with media queries). In addition responsive design usually means that the same resource and representation could manifest itself in different styles.

The problem with the traditional solutions

While this will work if the browser is capable of handling the representation, there are many use cases where it isn't. The most obvious example is the content provider that just doesn't care about the different devices and serves - for example - a desktop application to a mobile device. To circumvent this problems some companies offer a transforming proxy (a.k.a Split Browser).

Split Browser

There are many companies offering this solution, examples are Opera mini / Turbo, Amazon silk, Google data saver and Nokia Xpress. The following sequence diagram shows the flow. Note that in this sequence the http protocol is used but this doesn't have to be (e.g. Google data saver uses spdy). Even the response doesn't have to be web content (e.g. Opera mini uses OBML). The W3C has published a working group note how transforming proxies should act. For example it should provide an x-device prefix for every original HTTP Accept header. In addition the proxy should provide a HTTP Via header to the browser.

Note that in this solution the client is part of the web as it could dereference a URI. The Split Browser may partly transform the content for a better user experience but the interaction is originated from the client's user agent. A typical example is where a layout is restyled to make it fit on a small display.

Cloud Browser

While the above solutions provide the best possible representation they have one drawback. A user experience is always limited by the client capabilities. Even though a Split Browser could optimise the content the client needs to process the content. A Cloud Browser will circumvent this problem by terminating everything on the server. In concept, the browser exist in the cloud. The initiator (the client) is only triggering events but is not responsible for the resources nor the representation. It could provide an identifier but has no relation with a resource (e.g. id dashboard123 could point to a totally different resources on Cloud Browser from different vendors). You may compare it to a remote display (in reality it is more than a display though). From the Cloud Browser to the origin server it acts the same as a conventional browser. It is even possible to use any of the previously mentioned techniques such as content negotiation. Here is a simplistic sequence diagram:

This means that almost any client could provide a browser experience without constraints on the client capabilities nor the infrastructure. The client characteristics are less relevant in a Cloud Browser solution for the origin server as the Cloud Browser solution makes sure that the best representation will be provided to the client. Furthermore the architecture of the Cloud Browser is a bit different. For example navigation could be done by a separated device (e.g. a smartphone) and exposed to the Cloud Browser as regular DOM key press events. Since the client is abstracted and the Cloud Browser uses a virtual device instead, this solution has some challenges. An example is QoE metrics. Traditionally you will calculate the metrics agains the client where in a Cloud Browser solution this makes less sense since the Cloud Browser will enhance the experience (e.g. enable smooth animations on a device with limited resources). Obviously this is not a problem since you will get the correct metrics from the virtual device, however there are cases where it is less clear. Let's say the web application calculated the available bandwidth (which is the bandwidth between the CDN and the Cloud Browser) and based on this bandwidth it provides the best matching video asset. This will not work unless the bandwidth is exactly the same between the Cloud Browser and the Cloud Browser client. It is probably either more or less. There are many ways to circumvent this problem which the Task Force is discussing.