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.
Next question please
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
I'm interested in how this protocol can help glue together applications for better/easier/simpler distributed computing
With all the cheap servers with multi-cores we have, it seems like we all have the ability today to do distributed computing on our own grid.
This site (and corresponding book) Enterprise Integration Patterns was very enlightening to me as I thought more about messaging and less about imperative programming.
New technologies like Terracotta (for Java) make distribution simple, too. Everything works on the POJO model, but the POJOs are distributed magically via some fancy AOP code weaving. I wrote a blog article about how I used TC to make a message bus. It's been a very interesting project, thus far.
I can't speak for other companies, of course, but my company is moving toward a grid model with messaging forming the backbone of our processing. It's easy to scale horizontally, queue consumers all over the network form natural bulkheads protecting them from other components, and it's easy to throttle by having bounded queues and fixed numbers of consumers.
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.
In other news, water is found to STILL be wet!
XMPP has been used for a while now, bit late are we?
Please, for the love of god, can we come up with more useless acronyms?
Ugh!
My Slashdot Journal! YAY!
Twitter like service? Is it in fashion to have anyone reading your IM conversations these days? I noticed, that - predominantly - japanese use Twitter like any other IM service. Since anyone can read those messages, unless you make them hidden, this looks like a new sort of communication policy. I do have a twitter account, but I'd never use it as any other IM service, maybe I'm still stuck in 90's Internet but I can't see why people like having other people read their messages. Do I make any sense?
EOF
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
XMPP on a desktop is just another chat protocol. But, if all the cool kids start using IM services on their phones all the time, then it's game changing. The mobile carriers loose money on SMS, but gain it on data services. The SMS aggregators are out in the cold. And every web company/service now has a potential attention getting messaging system that they can tie into what they're doing/selling.
****
"I'd never want to join a club that would have me as a member" - G. Marx
with pubsub in place, an implementation of e.g. XEP-0154 [1] could easily be used to make privacy-enabled decentralized online social networking possible. the privacy fetishists could have all data on their own server and for the uninformed masses, well some web 2.0 crackpot could surely provide a web frontend ...
[1] http://www.xmpp.org/extensions/xep-0154.html
One can even impliment a better Internet (Http) using XMPP.
Like XMP, which is pretty much XMLJPG except the XML and JPEG data are either kept in separate files, or the XML is embedded inside the JPG rather than the other way around.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Especially anything that
1) can overcome real difficulties (Something which overcomes the design principle that everything should be "downwards compatible" to be transported over web servers/proxies/http or funny extensions/hacks of these, overcomes a real problem).
2) Is supported by google
has chances to be a big thing.
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.
Gtalk uses the XMPP protocol . :)
Mod me insightful now.Please please.I have never had a +5 before.
The problem with XMPP is not that it is a bad idea or that it is a bad spec, it is that they chose the heavy XML as a container format for the messages.
It is pretty silly that in a a 4-5 word IM message, 75% of the data transferred in an XMPP client is just protocol overhead, and the message is just 25%.
If they had used a more lightweight container like JSON for the protocol it would have much less overhead.
Frankly, IMO, almost all data transfer protocols would be better suited to the JSON container than XML container. XML formats only make sense when you have a complex hierarchical structure with lots of data types. Simple data types and not complex hierarchies make more sense in JSON.
I looked around but couldn't find anything about this problem with Pidgin.
The Mugshot application by Redhat uses XMPP for communication with clients. Its a good example of scalability of JavaEE and XMPP as transport .
404 Not Found
Mostly because most browsers really don't like it when you leave an HTTP connection open for too long, even if you set them not to timeout.
Google's actually come up with a neat hack to deal with this -- leave the connection open for 30 seconds, and if nothing new comes down it, close that connection and open a new one. Technically "polling", but practically just as fast as XMPP.
Don't thank God, thank a doctor!
For example: The protocol states that a chat client should ignore a packet without a subject or body. What this means is that you can extend the message packet with your own XML namespace, and add any tags and attributes you want. Then you can use the packet as your program's transport layer for moving anything you want. So while you are chatting to your buddy, there can be a lot of data transfer activity happening silently under the radar. Whiteboard, multiplayer game chatter, P2P transfers, etc.
One thing in XMPP's design that I would like to see fixed is its current state of being client/server only. I would like to see a little bit of distribution in the network. For example, a MUC group sits entirely on one conference server. How is a server failure handled? And some routability would be good, like JXTA has.
Aw c'mon, it was a JOKE, people! :P
I've designed and written specialized implementations of XMPP, both client- and server-side, at previous jobs, and am pushing it again at my current job. Several posters have mentioned (correctly) several problems with the protocol, but for all its warts and strange design choices it does make a good protocol for routing XML.
And that's really what it is - a way to reliably (if implemented properly on both ends) route generic XML documents to where they need to go, without polling of any kind, and to monitor the status and availability of whoever's on the receiving end. It just so happens that this framework provides what is needed for a chat application, but that's just the surface. Lots of applications can benefit from this.
In my professional implementations, it has been used for anything from a "chat client on steriods" to a backend communications framework between various applications that as a whole form a business process. It's a good, flexible, and extensible protocol, and the basics are easy to implement.
http://about.psyc.eu/Jabber
So what you're saying is, "XMPP" is pronounced "jabber"? That's brilliant!
No really, I mean it. Just imagine, if the pronunciation of more acronyms were *completely* unrelated from their spelling, it would really spiff up meetings at IT companies -- by weeding out those who *think* they know stuff (hey "scasy" crowd, I'm looking at you).
("/." = "Slashdot", hmm not too bad but still a bit obvious.)
"Good news, everyone!"