System architecture and off-line theory of Google Gears

Google Gears for development purposes is how to make web applications to reach off-line browsing. However, to promote off-line feature, there are always some issues that must be considered:

I. How to set the data layer

II. Decide when to take online or offline, or connection strategy III. Select how applications present in on-line or off-line state IV. How to construct the synchronization functionality

We illustrate in accordance with the above four issues as following:

I. How to set the data layer

The traditional web applications, users should be through the application programming interface to send requests directly with the remote server. There is no data layer between the two settings:

Figure 2-1 Traditional requests

Google Gears join the data layer on the local side; it is an access point to store information what applications request for. So the remote data will have a place to store on the local side. And then, the application interface will obtain information sources from remote capture, change to obtain the data layer. As shown below:

Figure 2-3 Join the data layer

Then add data switch layer, used to determine the source of pages of information is from an data layer (locally),or directly from the Internet (external) to obtain, it still can both use; when the information of data layer needs update, this layer can decide when to write data locally, or sent to Server for synchronization. As shown below:

Figure 2-4 Data Switch layer

Google Gears use another way to create a new local data layer; the layer uses a Gears database instead of going to the web server for data. In the off-line case, data switch layer request information for the Local Data Layer, and then Local Data Layer get webpage data from the Google Gears database:

Figure 2-5 Database of Google Gears

II. Decide when to take on-line or off-line, or connection strategy

Off-line web technology need to consider when to use local information or replace the server directly connected at different timing, known as the "connection strategy".

Although the better efficiency is that access information from the local, but actually, a local server, not all suitable to replace the information provided by remote server.

For example:

Source server for the real-time stock quote system

Server contains huge amount of information

Based on the speed of local side is faster than the remote, so the better approach is still possible store by the local side. In comparison, the greater amount of information stored on the need to synchronize the greater amount of information.

III. Select how applications present in on-line or off-line state

There are two modes that applications are displayed or not in off-line state.

The two kinds of differences:

The application displays off-line mode:

There will be some differences between on-line and off-line state. Sometimes users need to switch the mode themselves.

Such as: Google Reader: It will connect with server in on-line state or use local offline storage. Information will be synchronized each time when the users switch. This model is relatively easier to implement. Drawback is that users need to remember to do mode switching, or sudden off-line will be no information available; if the network quality is unstable, users need to get alternative use for the model.

The application does not display off-line mode: There will not be any significant difference. The user does not need to switch connection mode, the program will operate automatically.

Such as: GearPad: It is destined for off-line execution environment, so at any time if we lose network connectivity will not be affected. This model allows users to ignore the state of mode switching network, even in the unstable network can continue to use as usual. Drawback is not easy to implement, we need to avoid consuming too many resources for background synchronization,

then decrease the overall performance. Synchronous operation has nothing to do with user activity, so testing difficult.

IV. How to construct the synchronization functionality

Usually, through the operation of program, the contents of the local and server will be different, when the connection of network works, the contents need for synchronization; synchronous operation mode can be used manually or background.

However, Google Gears does not provide synchronization engine, which must implement by the application developer according to their own development.

 Manual synchronization

As the manual synchronization is not at definite time, so every time they must pay attention to the problem of load limits. In addition, users may not understand the situation on the network, only find the network is not available when they try to synchronize, or forgot to synchronize before they enter an environment which network is not available. Manual synchronization with easy to implement, but require user participation features.

 Background synchronization

In a network available environment, the application can be continued synchronization between the local side and server, and detect the network connection before doing synchronization. In such way, if a sudden failure or instant off-line, we still can maintain the latest information.

Below is the Google Gears chart includes background synchronization.

Figure 2-6 Sync Engine of Google Gears