Slashdot Mirror
Is XMPP the 'Next Big Thing'
Open Standard Lover writes "XMPP (eXtensible Messaging and Presence Protocol) has been getting a lot of attention during the last month and it seems that the protocol is finally taking off as a general purpose glue to build distributed web applications. It has been covered that AOL was experimenting with an XMPP gateway for its instant messaging platform. XMPP has been designed since the beginning as an open technology for generalized XML routing. However, the idea of an XMPP application server is taking shape and getting supporters. A recent example shows that ejabberd XMPP server can be used to develop a distributed Twitter-like system."
XMPP has been designed since the beginning as an open technology for generalized XML routing. However, the idea of an XMPP application server is taking shape and getting supporters. A recent example shows that ejabberd XMPP server can be used to develop a distributed Twitter-like system.
Minus two points for not managing to cram the phrases "AJAX" or "Web 2.0" into this writeup.
The theory of relativity doesn't work right in Arkansas.
My next project is a field test of a XMPP based Single-Number-Service-System for Siemens phone system, the OpenScape 3.0. Seems that there is really some XMPP around right now.
E-Mail wrapped in an XML overcoat.
... I must remember to file my patent application for XMJPG ... a JPG file wrapped in XML for instant dissemination of boring holiday snaps to people who I became "friends" with by virtue of the fact they happened to be in the same universe as me and also owned a PC.
Is there NOTHING sacred that some lemon won't wrap in XML ???
Oh, no, wait
Brilliant !!
To try to standardise how this is pronounced? eg. "wizzywig", "scuzzy" etc.
'Zemp' would be a nice easy way of saying this.
One thing often overlooked by people is that is kills vendor lock. There are several government agencies which use a proprietary messenging system for instant messenging. Once you introduce true XMPP-compliant products, this kills the stranglehold that some of these vendors have. I'm sure this is true outside the government too.
How to Download YouTube Videos
I poked around their web site and could not find anything about the performance of the protocol. We do a lot of XML based communications at work and even for simple messaging, we find that there is definitely a drop off in speed compared to less verbose techniques. Not just in terms of transmission speed, but a lot of time is spent in the XML parsers. Perhaps this is a by-product of using the XML classes in .NET, but that's the technology we're stuck with. If anyone has some simple benchmarks or tests of XMPP, that would be interesting to see.
XMPP is what Jabber is based on. Jabber, for those that don't know, is a chat protocol. It's used by Google Chat, Livejournal Chat, and vast numbers of other chat systems - all of which are interoperable, because built in to the underlying system is the idea of message passing from server to server.
If someone connected to a gmail jabber server sends a message to andrewducker@livejournal.com then google chat automatically connects to the livejournal jabber server and passes the message over.
You can see how this could be extended to allow federations of application servers to communicate. Heck, you could reimplement email over this without massive difficulty.
My Journal
"that ejabberd XMPP server can be used to develop a distributed Twitter-like system."
What the hell does that mean?
I don't know whether to apply the "alphabetsoup" tag or the "stopturningnounsintoverbs" tag.
"As God is my witness, I thought turkeys could fly." A. Carlson
You should never let people know hen you don't understand an abbreviation. To impress the geeks you should express an opinon even if you don't understand what the hell TFA is going on about. Examples
Could an ejabbered XMMP server really be said to be Twitter-like?
I don't think that Twitter-like systems are the way to go here.
That's really cool, we could really use a Twitter-like enjabered XMMP server here. It will revolutionise computing!
Say what you will about Google and privacy concerns, but this is one case of Google doing something good. If they hadn't used Jabber/XMPP for Google Chat, I doubt that we would be seeing this level of interest from others. Just about everybody that I chat with uses Google Chat now, and so, for the first time they all use Jabber capable clients. This is a very good thing. If Google goes out of business, or just becomes unpopular, the infrastructure will now be there to somewhat effortlessly transition to a new dominant IM system that is based on open standards, instead of going back to the days of MSN, AOL, Yahoo, and ICQ, all fighting each other and their users.
Please, for the love of god, can we come up with more useless acronyms?
Ugh!
My Slashdot Journal! YAY!
Perhaps it is just the library I've used to develop an XMPP client, but I found implementing a client a complete PITA. Most specifically I couldn't find *anything* that simply stated you have to do X, Y, and Z to "do" XMPP. It required a lot of trial-and-error (lots of XMPP packet dumping) with another XMPP client to "subscribe" to someone else (aka get on their buddy list), to notify everyone you're online, and to send messages. All of the RFCs and JEPs are neat if you know what you're doing, but otherwise it just confuses the hell out of you trying to figure out exactly what it takes to make even the most basic client.
XMPP also requires you to keep a fair amount of state information. Stuff I seemingly would think should be kept by the server. I suppose by making the server really dumb (basically a router) you really put the eXtensible in XMPP but at the cost of a more complex client.
On its surface XMPP looks great: an open-source IM protocol!! Once you, the newb, get into it it gets really ugly.
Then again, maybe I made a poor choice in a python package or I just happened to not find that key page with google that basically explains my problem away (and that's all it is is acclimation, it's not terribly difficult once you "get it"). Not even the wikipedia page explains inner-working details of XMPP. And FWIW, I was *trying* to do what this story was saying XMPP is going to be so great for: server glue for a distributed web-based application. Where I sit now with what [little] I know: I completely disagree until someone wraps it all up into a super-easy library (which shouldn't be too hard).
:wq
I wrote a php xmpp client and server a few months back. In my humble opinion it is a poorly-designed protocol.
For one thing, it is an example of how NOT to use namespaces in XML. Many elements are needlessly separated out, causing a lot of confusion and problems for simple xml parsers. Namespaces do not solve the problem of name conflicts, as the xmpp site still has a registry of namespace names. Separating out extensions - maybe, but the whole point of namespaces is to avoid conflicts when two _disjoint_ entities are working with the same schema. Here we have a central authority on the protocol trying to partition itself. This makes no sense to me. Even if you want to separate extensions from the core, there is still a better way to do it and keep everything simple and elegant - two things xmpp is not.
The protocol is bloated. Again - my opinion. But compared to something like XML-RPC (in terms of syntax and structure), XMPP feels like everything was an afterthought that didn't fully fit together with the original design. The separation between presence, iq, and message stanzas feels extremely awkward and arbitrary to me. Why not have a single stanza, with an attribute that defines its type? Get rid of namespaces, and have a registry of node types I you wish. Think of how much cleaner the protocol would be.
Likewise, this protocol seems like it was designed for humans - having a computer use it doesn't seem to be on the agenda. This comes out in the fact that no abbreviations are used to try and make XML data a bit smaller in size. Why would you design a protocol for use in real-time and keep things stanzas? Yes, you can use compression, but not all clients and servers support it. Think of how much bandwidth is wasted transporting useless information between computers. If I was designing the protocol I'd try and shorten all of the most commonly-used elements - instead of . Put computers and resource limitations before human convenience. You get rid of 6 additional bytes from the message stanza and processing is also faster. You may think I'm just going on about nothing here, that it doesn't make any real difference, but consider what a change like that would do to servers processing several thousand message stanzas every second.
On the same topic of being designed for humans, an xmpp session (from start to end) looks like a perfectly valid xml document. You have a root element (which is closed at the end), and stanzas in the middle. Again, this is appealing for a human, but it makes code very ugly. Why in the world would you design it this way? Why should I have some special code to deal with an opening element that is never complete till the session is over? I already have an xml parser that deals with complete xml structures, and a piece of code that waits until a full stanza is received before processing it. Why not make it easy FOR COMPUTERS to deal with, and allow me to use that code for ALL xmpp communications. Hell, make each stanza a separate document. This is again a case where the designers thought "what would a human find most pleasing," and completely ignored the needless complexity in implementation added by their decisions.
I could go on and on describing problems with xmpp, but you have a rough idea here. Personally, I would hate for this protocol to become the standard for IM communications. It is bloated, needlessly complicated, and very awkward to use and implement. Sadly, I think with Google's support it will become the standard, and sooner or later something else will come along with another protocol causing a continuation of the IM wars.