In XMPP, there are three types of stanzas that can be sent between entities.

• Presence stanzas declare an entity’s availability. Offline, available, unavailable, in a meeting, at school, having a bad day and not wanting to talk, or anything else. At the lowest level, however, it is an on-off switch; either present or absent.
• Message stanzas are a “fire-and-forget” way of getting a piece of information from one entity to another without worrying about getting anything back or even about whether or not it is actually delivered. Messages can have any kind of payload.
• Info/Query stanzas, also called IQ stanzas, are transmissions that follow the request/response model familiar in the HTTP world. They even have a comparable set of verbs. An IQ stanza with a type of “get” is equivalent to an HTTP GET request, and a “set” IQ stanza is equivalent to HTTP POST or PUT requests. HTTP responses compare to IQ stanzas of types “result” and “error”

So the one piece of functionality that HTTP does well is the request/response model. On today’s web, this is no longer practical for realtime bi-directional communication. However, for the purpose of fetching a web page, this model is perfectly fine. For this reason, the new XMPP web will most likely use XMPP’s IQ stanzas for that purpose. Here is a simple illustrative example:

Here is the punch line: I am going to make a web browser and server that use XMPP to communicate rather than HTTP.

Here is the current status: when you visit a website, your browser talks to it using HTTP, which was meant to work like this: your browser sends an “HTTP request” and the server sends back a response, and that’s that. That was fine for what they were doing with the web in the 80s, but now we want more interactivity. So along came JavaScript, allowing dynamic and interactive manipulation of webpages that had already been downloaded (via an HTTP request). The main two things that were missing were the ability to get new information from the server with out reloading the page, and the ability to send information to the server also without reloading the page. Then they made the XMLHTTPRequest JavaScript method, which allowed XML (or anything really, it’s actually a misnomer) to be sent from JavaScript code directly to the server (over HTTP), thus forming an XML HTTP request (get it?). This is what we use now, but it still has a major problem: the web browser must initiate the request. Currently, most dynamic sites use polling to get info from the server. That is, they periodically say to the server “Hey, is there anything new?” and if there is, the server will send back the new information. But this is slow, stupid, and takes a lot of resources. The newest approach is to replace polling with a technique called “comet” which basically means that the web browser just makes one request, saying “Hey tell me when there is something new” and the server sends it’s response but does not terminate the HTTP connection, leaving it open to send new information down when it arises. This is freaking stupid, for several reasons, the most important of which (and the only one I’m concerned with) is that HTTP was simply not built for that.

My solution (although I am certainly not the first to think of it): the web browser, instead of making HTTP requests to servers, initiates XMPP sessions with them. XMPP, or eXtensible Messaging and Presence Protocol, is the underlying protocol used by many instant messaging systems, notably Jabber and Google Talk. When they say that XMPP is extensible, they mean it. There are 200 something proposed extensions to the XMPP-Core specification, as well as a great many proposed extensions to the Jabber instant messaging specification (which is itself an extension to XMPP).

So making an XMPP extension oriented toward web server/client interaction will certainly be possible, and likely not terribly difficult. In fact, what gave me this idea is that Google Wave actually uses XMPP for much of its communication, including for federation between Wave servers. The open source Google Wave Prototype server is actually a component meant to be run alongside an XMPP server (the instructions use the OpenFire XMPP server, but people have gotten it working with other XMPP and Jabber servers, such as ejabberd).