Update: Reading all the JEPs it seems to me that Jabber unfortunately steers in the direction of design by comittee, the JEPs create a baroque jungle of overlapping capabillities and the developers have no clear message what to choose for a particular feature.  For example read this mail from the Jabber Dev mailing list: http://mail.jabber.org/pipermail/jdev/2005-September/021918.html

Update: [http://www.jabber.org/jeps/jep-0004.html JEP-0004: Data Forms]

Everyone thinks about building Rich Internet Applications using the old HTTP transport mechanism, but perhaps Instant Messaging (and particulary the Jabber - [http://www.xmpp.org/specs/ XMPP] protocol) is better positioned to become the platform for building them.  Jabber is well suited for this role because, just as HTTP, is as an universal protocol, not tied to any operating system or other platform. 

Of course it is hard to predict anything here, because one need to take into account not only the technical advantages of one technology over the other but also all the habits people developed when using and thinking about particular technology.  This is crucial because it is people who develope applications for platforms and without applications a platform will never gain enough momentum.  But bots, chatrooms and other extensions just now offer possibilities for new applications all adding to the critical mass.  This is very similar to the role of CGI in HTTP.


The advantages of Jabber over HTTP:
* with less entrenched habits can change faster than other technologies
* uses a continues connection instead of the stateless transactions of HTTP
* [http://www.corante.com/getreal/archives/gen_y_and_the_coming_communications_revolution.php Gen Y and the Coming Communications RevolutionEmail This Entry] IM is the young generation communication tool of choice
* [http://www.jabber.org/jeps/jep-0060.html JEP-0060: Publish-Subscribe] offers a generic event driven communication platform

This prediction will work only when IM authors would give up producing new incompatible protocols and instead focuse on one common basic technology (the best candidate backed by IETF is of course Jabber) and only add extensions to support for new functions.

Examples of IM applications: 
* [http://www.huminity.com/ Huminity] Social Networking in IM (Social Networking fits better to IM than to web since IM from the beginning use the same basic vocabulary - 'friends lists')
* [http://www.engadget.com/entry/1234000620020904/ IMSmarter]: “secretary that helps you out by sitting between you and the rest of the world, letting you know about things that are interesting and taking notes of your meetings so you can recall what was said later.”

What we need now is a language interpreted on the client side for creating user interfaces, for the beginning omething basic like HTML with forms for CGI, it would improve over time. With chatbots we are back to command line.

----
See also: SynVersusAsyn for comparison of functions of Synchronous (Real Time) and Asynchronous Communication.