Following my post on WebSockets availability in Chrome, I looked around to see what are the options for asynchronous communication over HTTP without WebSockets. Below, I list the available approaches prior to WebSockets and I will also discuss the pros and cons  of these approaches.

We know that HTTP is a synchronous request/response application protocol and in which a client always initiates a request and the server responds to the request; the server never initiates a request to the client. This communication pattern limits HTTP applications to synchronous “pull” only interaction pattern. However, there are several approaches that emulate asynchronous communication over a synchronous communication channel. I briefly explain each method with their pros and cons below:

Polling ( also called Pull Technology)

Polling requires the client to send request to the server at regular intervals to check if there are any updates. Server events can be queued and delivered to the client on each request from the client emulating server initiated communication.  The polling interval can be fixed and determined based on the application requirement or the server can indicate polling interval in its responses.

• Advantages
  • Simplifies server implementation by not requiring the server to maintain a list of subscribers and by shifting the responsibility of guaranteed delivery to consumers.
  • Stateless interaction
• Disadvantages
  • True real time communication not possible and is bound to the poll interval.
  • Uses up server resources unnecessarily
  • Will have to strike a balance between shorter and longer poll intervals to improve efficiency
  • Increased network traffic (can be reduced by using conditional GET

Long Polling

This is a variation of the polling approach in which a client sends a request to the server and the server sends a response only if there is information to be sent in the response. If the server determines the requested resource is not changed, it holds on to the request until the resource is changed or if the specified timeout expires. When the server sends out the response either due to updates in the requested resource or due to timeout, the client issues another request and whole cycle repeats i.e. the server always has a pending request from the client.

• Advantages
  • Better real time communication compared to normal polling because the information is sent as soon as it is available.
• Disadvantages
  • Open HTTP connections consume system resources.
  • Each request will a require thread that blocks the requests until data is available or till timeout. If there are multiple requests, this will result in large number of threads blocking for data.
  • Server side support for asynchronous request processing (Asynchronous I/O) is required for scalability.
  • No standard mechanism available. Each environment has its own mechanism to handle long polling.

Streaming

HTTP streaming is similar to long polling except that the connection is never closed even after the data is pushed to the client by the server.  In this approach, a client sends a request to the server and the server responds to the request by sending data back to the client. However, after the data is sent, the server does not close the connection but instead keeps the connection open and pushes data to the client whenever available over the same connection.

• Advantages
  • Allows sending multiple data transmission over single connection and results in fewer requests to the server.
  • No connection over head.
  • Real time updates possible.
• Disadvantages
  • No standard mechanism available. Each environment has its own mechanism to handle streaming.
  • Might not work through proxies/firewalls
  • Might result in large number of open connections when there are multiple requests.

WebHook

WebHook provides a HTTP callback via HTTP POST when an event occurs.  A Web application implementing WebHook will POST a message to a specified URI as an event notification. It also allows clients to register custom URIs with Web application which then POST messages to these URIs to indicate state changes. The notification URI should point to HTTP server.

• Advantages
  • Provides near real time updates.
  • Standardization attempts via WebHook and PubHubSubHub initiatives
  • Polling is eliminated.
  • Fully asynchronous
• Disadvantages
  • Might not work through proxies/firewalls
  • Requires the receiver to host a HTTP server.

For our RESTful application, we started off defining a domain specific XML vocabulary but ended with a generic XML vocubulary to describe resources. One of the major goal of vocabulary definition was to have the ability to describe all resources in uniform and consistent manner. Initially we started designing the vocabulary around the semantics of each resource and found out soon that it was harder to mantain. We then decided to make a generic “resource” vocabulary i.e. the vocabulary was aimed at to be applicable to a large set of resources as possible. We also based our design on the needs of the client rather than around the specific resource. The design considered that anything exposed by our application is a resource which can be linked and provides links to other relevant resources. We have also tried to follow the basic software engineering principle of “Applying the software engineering principle of generality to the component interface”.

As per REST, a Resource is defined as:

“The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource”

Thus a resource is the fundamental building block in a RESTful system. A resource can have properties of any type (xsd: or custom) and can also contain resources. Based on these assumptions, we have come up with a generic XML vocabulary to describe all the resources in our system. I will post the vocabulary in my later posts.

A Wave is queued for deletion from our system once all participants who have access to the Wave remove themselves from the Wave. Residual copies of deleted Waves may take up to 60 days to be purged from our servers and may remain in our offline backup.

Even though there is only one copy of a wave in the system and even though you are the creator of the wave, it is not easy to delete it. You got to remove all participants but there is no way you can do that except ask all participants to remove themselves (which is currently not implemented). So currently the only way is to ask all participants to delete the wave and wait for 60 days for it to be removed from system but still there is no guarantee that it will removed from Google’s backup store!

#TARGET=desktop

TARGET=browser

./configure –target=$TARGET ….

1. Intel backs Google’s Chrome OS
2. Microsoft’s Gazelle
3. Microsoft to unveil Office web

This is exactly what we need; a good competition to get the best out for the community.  I hope more players join in the competition.