As more and more websites and applications start moving to using the AJAX paradigm , people are going to hit this problem of how to use HTTP as a transport 'reliably'.
What I mean is , HTTP is essentially similar to a one way datagram approach to communication.
You send request A , wait for response A - move on.
Since this need not be a direct connection from client to server (even if it was) , the request could fail to be delivered , response could be 'lost' , connection errors , etc could intervene.
If they are idempotent methods being made , then you can reissue them in case the request fails for whatever reason.
If not , things are slightly trickier - but there is some sort of support in most frameworks on how to handle this currently.
Add HTTP/1.1 persistent connections to this mix and things get really interesting - one socket fails : and a whole bunch of requests are lost.
Also, AJAX typically issues POST in most cases - a non-idempotent method.
Add to it the requirement to 'poll' the backend for data or updates and you have a interesting problem : you are trying to simulate a HTTP client into being something similar to a bidirectional stream : simulate is a key word here , mind you !

So you have requirements to 'manage HTTP as a transport' coming both at the client side and at the server side.
In the XMPP world , when support for HTTP was initially added the first approach was a pure polling solution.
As can be guessed , they later developed the HTTP Binding solution under JEP 124.

This is a very very interesting extension and I believe is the key to solving most of the problems above.
Though defined for XMPP , it is a solution to essentially act as a transport for any xml based protocol : only requirement, one or more "full xml stanza's" are exchanged - not partial xml data.
It solves the problems of retransmission , session management (no need for cookie's , url rewriting , etc) , support against replay attacks , etc.
Heck , we have XMPP - a purely xml based streaming protocol working on top of this successfully !

How does this help AJAX ?
All the browser based XMPP clients which support this JEP have some variants or other javascript library in place to actually do all this.
So , potentially you could have :
<your application> --> <jep 124 client side js library>   --- HTTP ---> <HTTP Bind gateway> <-- Custom protocol --> <Your server>
With suitable modification (IF your app is not XMPP that is ... why not move to it? Read prev post on some advantages) , you can use the ideas from JEP 124 to solve a whole bunch of problems with using HTTP as a reliable transport.
Add to it the fact that you already have server side and client side opensource component's available to support this - and you have the perfect solution just waiting to be used.

Happy coding !

  In this post , I briefly try to push how XMPP can be used as a infrastructure - and not just as 'yet another chat protocol'.
It is not as descriptive or authoritative as I would like it to be ... but here goes nothing.

The abstract from RFC 3920 says :
"This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779."

For the purpose of this discussion , let us take a small subset of what XMPP provides which allows us this :

1. As specified in section 4 of 3920 , an xml stream between two entities which allows for exchange of structured xml stanza's at realtime.
2. A binding to tcp and defines how to secure and authenticate the stream.
3. Defines the top level stanzas allowed in this xml stream. These model request-response , broadcast and one way meps.
4. Server federation , routing rules , multiple resources per node built into the protocol.

Let us consider the implications of these.
We have an authenticated and secure stream between two entities - so this asserts the client identity.
This explictly identifies an entity within , not only its server - but if federated , across the XMPP universe of federated servers ! This guarantees that any stanza orginating anywhere in this grand federation of XMPP servers will be unambigously routed to this specific client endpoint
Defines an xml stream ... most data transfer protocols have already moved , or are moving towards standardizing on usage of xml : so XMPP provides a native transport mechanism for these.
The MEP's supported allows us both synchronous communication and asynchronous notification - in either direction: hence both push and pull models are natively supported.
The protocol itself allows for presence notifications through a publish subscribe model.

Now , the XMPP community has come up with a variety of protocol extensions which have been standardized as JEP's.
A few notable ones which are relevent for this discussion are :

• A flexible discovery mechanism : allowing various clients/servers to interoperate. It helps either side to discover the supported subset and allows protocol extension without breaking compatibility.
• Multi User Chat - though it defines how to set up a 'chat room' : it can be used or modeled to multicast message's to a subset of interested entities.
  
• A powerful publish subscribe extension for XMPP.
• Advanced message processing allows specifying additional delivery semantics for messages.
• HTTP Binding - allowing XMPP to be bound to HTTP. (More on this later)

All this taken together allows for providing solutions for some challenging problems.
We could use xmpp as a middleware for realtime communication and use it for both synchronous and asynchronous notifications. Some examples :

1. Pushing information to interested entities - like stock quotes to customers or brokers , etc.
2. A whole bunch of publish subscribe usecases can be solved.
3. Multicast stanza's as messages to interested entities.
   
4. Allows us to write presence aware applications - the entity in question need not really be another 'person' ! Also , use of CAPS and PeP will definitely make this world of applications much more interesting !
   

Now , add JEP 124 (httpbind) into this picture and things become really interesting.
Httpbind essentially can be considered as way to tunnel a xml stream based protocol on top of http : no , not the old CONNECT hack that most implementations use , nor a dumb frequest poll mechanism.
As an analogy , you can consider it to be similar to how you would simulate a persistent stream on top of UDP - only it is HTTP here instead of UDP.
The extension takes care of retransmissions , packet loss , request/response id , etc and makes allowances for HTTP characteristics .

Hence , all the power of XMPP is now available over HTTP.
So be it a rich client application or a rich internet application - both can talk XMPP and harness its power !
And with it , allows all usecases of using XMPP as a realtime messaging middleware available to all developers/users on most platforms - be it a RIA or a thick client.

XMPP - coming to a browser near you

Here is a report from CNET News talking about Sun regaining market share - and more importantly , gaining revenue while all other major vendors lost !