Is XMPP the 'Next Big Thing' 162
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."
Am I too late... (Score:5, Interesting)
'Zemp' would be a nice easy way of saying this.
XMPP as a silver bullet? (Score:5, Interesting)
Performance (Score:3, Interesting)
WTF? (Score:2, Interesting)
What the hell does that mean?
I don't know whether to apply the "alphabetsoup" tag or the "stopturningnounsintoverbs" tag.
Re:buzzwords are my favorite (Score:5, Interesting)
Re:A brief explanation (Score:4, Interesting)
Heck, you could reimplement email over this without massive difficulty.
In reality I think it was one of the first things they implemented in Jabber. A lot of clients, especially the hardcore jabber clients, have different messaging modes: one mode composes a single message, another mode opens up a little chatbox. If you examine the former, you'll find that it's exactly like e-mail, although really it's just a jabber message. Everybody ends up using the chatbox because that's what jabber is for, and many popular clients (eg Pidgin) have only that.
In terms of server and protocol, in my opinion Jabber is fully able to do e-mail. In fact, I'm sure Jabber servers already have e-mail gateways. You just need a client that operates in a manner that implements e-mail as we are used to; for example, most clients just pop up offline messages as soon as you connect, or mark them on your roster instead of presenting you with a stored list of messages that you can manipulate mailbox style.
Re:buzzwords are my favorite (Score:2, Interesting)
Remember, YMMV.
XMPP is a PITA (Score:4, Interesting)
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 [wikipedia.org] 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).
Re:Thanks Google (Score:2, Interesting)
Re:Am I too late... (Score:4, Interesting)
If the guy can write an XMPP client, and knows exactly what is wrong with Pidgin's implementation in order to "fix" his client to support it, then he should be more than capable of providing a fix to Pidgin's code, so that he doesn't have to keep fixing his code, and the all of us Pidgin users can benefit as well.
Let's hope not (Score:2, Interesting)
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.
Re:A brief explanation (Score:3, Interesting)
only thing about using xmpp as a mail "replacement", can it do attachments?
no, im not talking about file transfers, im talking about attaching the file to the xmpp message and have it be stored on the server if the recipient is offline at the moment.
thats the one strong suit of mail vs sms or im right now, that you can fire and forget a file rather then having to watch for a person being available to accept it.
still, xmpp will not take of in europe unless microsoft gets on board, as the msn/live messenger seems to have a strong posision here. and thats a cold day in hell scenario.
Re:XMPP is a PITA (Score:3, Interesting)
Look at the documentation provided by jabberpy. It's computer-generated pydoc with pseudo code on making a simple client. Did they have time to write an entire jabber library but couldn't taken the 45 seconds you did to write actual code instead of pseudo code?
Now when you take your bare example and try to receive messages then your simplicity isn't there any more. Thrown in presence and rosters and your "it's that easy" argument goes out the window for someone whose only resource with "the answers" is the RFCs themselves.
After all, if trying to do server glue (as the story summary promotes) then that necessitates handling reception of messages, presences, and the other stuff that comes with it. I can't even remember how long it took me to realize I was getting disconnected from the server for idle timeout and then finding a suitable means to "ping" the server.
None of this is explained anywhere in anything resembling succinctness. Even the library you promote doesn't have it (if it does it's not in an obvious location). Like I said in another reply: when time is money the utility is much more important. If XMPP is "right around the corner" for mass-adoption then I must be using the wrong search engine because I can't find any GOOD XMPP documentation for those who want to use it and not write a dissertation on it.