I'm sure most of you developers know that situation: You are working on your day job and what you're doing is not really always the hottest thing on the technical earth, to say the least. So, some relieve and distraction is needed to recover at night. For the last 2 years I've been on-and-off working with XMPP (a.k.a. Jabber), implementing a server as a side-project. And that really gives me the kicks I need.

XMPP is a well-architected, well-standardized, powerful, yet reasonably simple messaging protocol. It was created with extensibility in mind and it has in fact lots of public and proprietary extensions, which all (if they adhere to the standard) are interoperable. (Which means: Any server or client can savely ignore them, if they don't know them.)

What makes XMPP such a natural choice for many messaging applications is that it supports the three major messaging paradigms: point-to-point, broadcast and request/response.

While the first two are used for communication between all clients with the server as a router (hub-and-spoke), request/response - or "info/query" (IQ) in XMPP terms - is used for client/server interaction.

XMPP is bound to a session based on a persistent TCP connection, much like POP3, SMPT, Telnet and similar line protocols. This is in contrast to HTTP which was architected session-less. That led to many workarounds to make sessions work between requests with HTTP, all those pains like cookies, encoding sessions in the URL, recycling TCP connections between request, long polling and whatnot. What once was considered an advantage of HTTP is becoming more and more a burden as servers are required to respond spontaniously to avoid client pull congestion.

Theoretically, with a persistent connection, the server can always push data to the client even when the client does not pull because he is off doing something else. But most of the established protocols like POP3 or Telnet refrain from doing so. And this has always been considered a good choice, since you as a server didn't want to overload your network and clients in times when network and CPU resources where precious goods.

In addition to client/server, XMPP supports server/client request/response, too. This does not create a problem since a XMPP client must be prepared to receive Messages and Presence from his peers at any time anyway. So if the server wants to know if the client is still alive, he can send him a ping IQ command and the client will respond with a pong.

To me it seems like XMPP opens the door for many new types of applications. It's developed by an open community but it lacks a server implementation which is open source in the ASF sense, with the right license and community setup.

So if you have some spare cycles, jump in and help out on Vysper at Apache Labs. See you there!