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."

buzzwords are my favorite

[User 956]

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.

Re:buzzwords are my favorite

[samael]

Except that XMPP isn't a web technology.

Re:buzzwords are my favorite

[Rogerborg]

Wash your mouth out with SOAP. Everything is a Web 2.0 technology.

Re:buzzwords are my favorite

[TheRaven64]

Why not? The web is basically a way of sending XML to users. XMPP is a way of sending XML to users. AJAX is an ugly hack. It's fine for sending data from the client to the server, but to get updates from the server you need to keep polling. With XMPP, the server can push XML fragments to the client whenever it wants and some client-side JavaScript could then process them into the DOM. There was a proof of concept a few years ago (before AJAX was a buzzword) where someone integrated an XMPP client into a web browser and used it to deliver updates to the page.

Re:

[Timothy Brownawell]

The web is basically a way of sending XML to users.

I thought the web was a way to let users find/retrieve arbitrary information.

Re:

[jdray]

AJAX is an ugly hack...[instead], the server can push XML fragments to the client whenever it wants and some client-side JavaScript could then process them into the DOM

Umm... Isn't that just a different ugly hack?

Browsers force polling.

[SanityInAnarchy]

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.

Re:

[Hatta]

Awesome. I've thought for some time that HTML and HTTP are being overloaded with crap they're not suited for. They're designed for the markup and transfer of hypertext, applications are not hypertext. I would just love for a real application transfer protocol to evolve and get this interactive crap out of my web.

Re:

[samael]

A twitter-like system could be built on top of xmpp. In much the same way that a gmail-like system can be built on top of SMTP/POP. That doesn't mean that SMTP/POP are web-based.

Re:

[jdray]

Now, there you go, starting one of those Slashdot-special meta arguments about what the nature of this "web" thing is. Back in the day, "web" was everything HTML, mostly running on port 80. One could argue that "web" is anything meant for direct consumption by a user (y'know, like through a browser), but that's blown on several fronts. Mail has become part of the web. So, where are the edges of the web? Where does it stop? Where does it start?

Remember, YMMV.

Re:

[Angostura]

Nope, mail hasn't become part of the Web, some mail systems have Web interfaces.

Re:

[jwilcox154]

A twitter-like system could be built on top of xmpp. In much the same way that a gmail-like system can be built on top of SMTP/POP. That doesn't mean that SMTP/POP are web-based.

I don't know if a twitter-like [slashdot.org] system would be a wise course of action for an instant messenger system let alone an instant messenger system using XMPP. Do you know what problems could arise from this? Text such as M$, Windoze, Micro$oft, or anything dealing with anti-Microsoft topics would pop-up in your message. This change could occur when you type in MS, Microsoft, Windows, or anything dealing with Microsoft; or just occur spontaneously. ;)

Re:

[erlehmann]

web == world wide web == you fail (in not-so-epic proportions)

Re:buzzwords are my favorite

[Niten]

Minus two points for not managing to cram the phrases "AJAX" or "Web 2.0" into this writeup.

Huh?

• AJAX = Any technique for combining the XmlHTTPRequest object (or sometimes just an iframe) with JavaScript and XML methodologies to create a more dynamic web page = buzzword
• Web 2.0 = Anything with a smooth logo, whose name is missing some vowels, and that looks like it might possibly be using AJAX methodologies = buzzword
• XMPP = A very specific set of protocols, currently being formalized by the IETF, that form the basis for an extensible messaging or presence system and happen to be based on XML = not a buzzword

Field test of XMPP based system

[Sique]

My next project is a field test of a XMPP based Single-Number-Service-System for Siemens phone system, the OpenScape 3.0 [siemens.com]. Seems that there is really some XMPP around right now.

Just what we (didn't) need !!

[Anonymous Coward]

E-Mail wrapped in an XML overcoat.

Is there NOTHING sacred that some lemon won't wrap in XML ???

Oh, no, wait ... 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.

Brilliant !!

Re:

[b100dian]

I for one see an LMPP coming (light-weight..) and then a JSOMPP..

Re:Just what we (didn't) need !!

[Enleth]

Have you ever actually SEEN this protocol in action, its specifications, functionality and security features? This is one of the few cases where XML is actually a proper, well-implemented technology suitable for the job. I've been using Jabber as my IM of choice for a few years already, and XMPP as a communication platform for a few non-IM projects and all I can say is that the people involved in its design got it right and created a really flexible, adaptable and secure technology.

Yeah, I know, this is Slashdot, where people like to spew completely uninformed pseudo-opinions, but this one is just too obvious. Well, happy IMing on unencrypted, stone-age, propertiary networks that force-feed you with ads and censor your messages, if that's what you want.

Re:

[Sancho]

Well, happy IMing on unencrypted, stone-age, propertiary networks that force-feed you with ads and censor your messages, if that's what you want.

XML doesn't solve any of these problems (and they're not all problems.) There's no technical reason that any given messaging service couldn't use SSL, and XMPP is extensible, and an implementation of it can be made proprietary enough to require a client that will force-feed you ads. Any network can censor messages, assuming they can read them.

Your post is overrated.

Yeah, I know, this is Slashdot, where people like to spew completely uninformed pseudo-opinions, but this one is just too obvious.

Oh, sorry, I guess you covered all of that.

Re:

[Sancho]

Value additions for using my specific service? Inertia? (AIM didn't start out by serving ads, you know.) Inertia specifically counts for a lot, as once you have your JID, you won't want to give it up (just as I wouldn't want to give up my e-mail address, even if my provider started doing things that I didn't like.)

XMPP is OK but would be better if JSON

[brunes69]

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 XM

Re:

[Randle_Revar]

Using XML doesn't automatically make something good, but it doesn't automatically make it bad either. XML was designed for moving data between different systems, and that is how XMPP uses it. And XMPP is certainly more lightweight than SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). Also, as far as I can see, JSON was created in the 2000-2001 time frame (ECMA-262 was ratified in late 1999) and the current JSON.org went online in 2002. XMPP was started in 1998.

Re:

[AuMatar]

No, XML was designed to be a human readable format. Using ti to transfer data between systems is abuse, its a waste of bandwidth and storage space. If a human isn't in on the loop, a more efficient protocol should be used to avoid the waste.

Re:

[benow]

Or you convert it to binary xml and compress it before it goes across network. XML is standard, easy to understand and easy to debug, and its verboseness goes away with a bit of work on either end.

Re:

[brunes69]

JSON is also standard, easy to understand and text based, just like XML. It just doesn't have all the overhead because it is very simple.

Re:

[great om]

xmljpg isn't such a terrible idea, frankly, since it would allow for richer metadata than is currently allowed (inside the file, not in an indexing DB), although --yes-- there are certainly easier ways to get around that.

XMLJPG

[metamatic]

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.

Re:

[Qzukk]

E-Mail wrapped in an XML overcoat.

My first impression based on the tools actually using it (like ejabberd) is more like "IRC wrapped in an XML overcoat where everyone is a lousy sexchat bot".

Re:

[19thNervousBreakdown]

I am a great sexchat bot.

Re:

[Just Some Guy]

E-Mail wrapped in an XML overcoat.

Yes, because RFC 822 header fields are the pinnacle of parser research. Have you ever tried to write your own mail client? Have you ever tried to write your own mail server? By comparison, I'm pretty sure I could knock out a minimal compliant XMPP server in an afternoon, and it would support Unicode for free.

But anyway, the biggest thing the "X" buys you is a lot of extensions [xmpp.org]. I'd say it's actually delivering on what it promises.

Am I too late...

[abigsmurf]

To try to standardise how this is pronounced? eg. "wizzywig", "scuzzy" etc.

'Zemp' would be a nice easy way of saying this.

Re:Am I too late...

[Anonymous Coward]

"ex-em-pee-pee"?

Re:

[Chrisq]

I prefer the slavic czemp.

Re:

[jdray]

To the Chinese (AFAIK), "X" is pronounced like the English "sh", making this "shmpp", sort of like the sound of a sack of flour hitting the floor. Mind you, IANACL (Chinese linguist), nor someone who regularly handles large sacks of flour.

Re:Am I too late...

[Bogtha]

A lot of people pronounce it "Jabber". The name "XMPP" arose when they were moving it through the IETF standardisation process.

Re:

[Rogerborg]

I'm looking at you, Pidgin [pidgin.im]. The account setup list doesn't even hint that XMPP is AKA jabber. That's self destructive pedantry right there.

Re:Am I too late...

[TheRaven64]

Speaking as someone whose frustrated with having to implement two code paths in a Jabber client - one for the standard and one for the compatibility with Pidgin - I'd be very happy for Pidgin users to stop connecting to the XMPP network.

Re:Am I too late...

[mhall119]

Wouldn't it be easier to just make the fix in Pidgin and submit a patch?

Re:

[vishbar]

Why is this modded as funny? As a Pidgin user, I'd LOVE to see someone fix the crapstorm that is their poor excuse for a Jabber client. If you've got the ability, do it...it would make a lot of people happy.

After all, isn't this what the Open Source ethic is all about?

Re:Am I too late...

[mhall119]

Yeah, I'm not sure why it was modded funny or overrated.

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.

Re:

[AikonMGB]

What exactly is the problem with Pidgin's XMPP/Jabber support? I use Pidgin for my MSN, AIM, and GTalk accounts.. and all three of them seem to work identically and without issue O_o

In case it didn't come across clearly, I actually am interested in knowing what it does so poorly with Jabber, since as an end-user I really can't say that I see what the issue is =(

Aikon-

Re:

[Just Some Guy]

Wouldn't it be easier to just make the fix in Pidgin and submit a patch?

I haven't seen the Pidgin code or dealt with the community, so this may very well be off base: perhaps it's darn nigh unfixable, or the authors don't readily accept patches?

Re:

[erlehmann]

you are right, pidgin is utter crap as a jabber client.

Re:

[Sancho]

What do you recommend for a good XMPP client?

Re:

[WuphonsReach]

We use Pandion for our Windows XP boxes at work to talk to our XMPP/Jabber server. There's also Spark, Miranda, OS X's iChat...

Hell, I'm just happy that I don't have to track license counts any more (like I did with e/pop Professional).

Re:

[Randle_Revar]

A list of clients: http://www.jabber.org/software/clients.shtml [jabber.org]
For a GUI client, I like Psi. Right now I am using the xmpp extension for irssi.

Re:

[Sancho]

I've messed with the xmpp extension to irssi. I know that it's a work-in-progress, but it seems very incomplete. There's virtually no documentation, either, and I was pretty disconcerted with the apparent lack of encryption (I don't know if there really wasn't encryption, or if the messages just aren't clear (No certificate found? Certificate not trusted on a server with a thawte cert?)

Re:

[Randle_Revar]

It is pretty basic right now, but I only have 2 people on my roster, and I actually chat with them about once a month max, so it is good enough for me (I also use irssi to lurk on the irc channel for the window manager Awesome). As far XMPP encryption, I don't know about TLS, but it works fine with Gtalk's legacy SSL encryption.

Care to elaborate?

[Nicolas MONNET]

I looked around but couldn't find anything about this problem with Pidgin.

Re:

[noldrin]

I'd prefer 'Zemppy' as it's more reminiscent of 'scuzzy' and 'wizzywig' and we do have that extra P to use.

XMPP as a silver bullet?

[webword]

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.

Re:XMPP as a silver bullet?

[rindeee]

Bzzzt...wrong. All IM in Gov/DoD is IRC based but moving to Jabber. This is public knowledge (not even U/FOUO). Lot's of commercial development going on around this if you Google around a bit. Some really cool stuff in the pipeline, especially where XMPP is concerned.

Re:

[TheSkyIsPurple]

Even more so, but I didn't see anything that specified anything about the data that the protocol moves around.

If I encrypt everything in a proprietary method (or with a proprietary key) and layer that into XMPP, you can still be locked in.

It's kind of like saying because it's stored in XML it's open...
<document>
h5847uhlib43o8fvacgos8
5rw4978hefw9348fqw34fg
f438gqwoluiaf4687wgoasd
</document>

There's my open document, so you can read it. (No, I didn't include a DTD, but just

Re:

[Tablizer]

All IM in Gov/DoD is IRC based but moving to Jabber. This is public knowledge (not even U/FOUO).

Aha! So the gov't *is* hiding UFO's in secret hangers. And do something about that stuttering problem of yours.
   

Re:

[Stray7Xi]

What he said is ridiculous because there are plenty of shops out there that setup their own solutions for their site.

However it's true on the intersite scale. All the services use Bantu, which is XMPP. They actually advertise themselves as the IM used by US govt.

http://www.bantu.com/products/BantuEIM.pdf [bantu.com]

Performance

[ronark]

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.

Re:

[mremond]

Actually, ejabberd is probably one of the highest performing XMPP server. It can supports tens of thousands of simultaneous connections on a single node and can work in a cluster. That's for a single domain, but with distribution as described in the protocol, each web site is his own domain. As you see, the scalability is handled. And on the raw message performance, it can handle hundreds if not thousands of messages per second in a cluster.

Re:

[rdradar]

XML definitely has lots of overhead and not needed bytes. However, it is easily expandable, easily readable (by human too) and can support lots of different kind of needs. Because XMPP is meant to be the universal IM protocol, it needs to be easily expandable. Normal, byte based protocols are harder to expand for all kinds of needs and you have to spend more time learning them, all individually.

A brief explanation

[samael]

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 [e-mail] 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.

Re:A brief explanation

[vga_init]

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:

[hitmark]

hell, toss in some kind of sms gateway and things really start to be 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

Re:

[wertigon]

Actually... Yes you can. There's this newfangled thing called the <data> element. But, it got pushed into a XEP like two months ago, so client support is rather limited, and it's only good for 8k for now... :(

If people starts using this much however, I can't see why the XMPP server wouldn't be able to store the file temporarily and then push it once the user is online. But, I think this is better for an xmpp/http hybrid.

Re:

[hitmark]

sounds like xmpp may well turn out to be the merger of all the existing text based communications systems then, nice :)

now to see thunderbird and the rest adopt it as a "mail" protocol of sorts ;)

Re:

[iabervon]

The main thing about email is that you can send it without publishing your presence, and you can send it to people who aren't online at the time. So it's a little more involved than the non-threaded chat mode, mostly in that the recipient's account needs a feature for holding messages (implemented by the recipient's server).

Re:

[MtViewGuy]

If I remember correctly, XMPP was developed specifically end the stupid war between various instant messaging systems (remember some years ago AOL IM had its own system, Windows Messenger had its own system, and so on). Hopefully, within a few years everybody will be using XMPP so people who are on AOL IM can "talk" to people on Yahoo! Messenger and other proprietary chat clients.

Re:

[Sancho]

There's not usually a good financial incentive for companies to provide IM, unless they're providing it in a proprietary way so that they can serve advertising (which is basically the only currently known way to "monetize" otherwise free Internet services.) As such, interoperability is rarely desirable, as you want anyone who talks to people on your network to have to sign up on your network, allowing you to serve ads.

In fact, the only reason I can see for a company to move to XMPP (or to include an XMPP g

Re:

[coolGuyZak]

...serve advertising (which is basically the only currently known way to "monetize" otherwise free Internet services.)

Client-side IM services achieved "commodity" status some time ago; monetizing them shouldn't be on the agenda, for the most part. However, server technologies & protocol extensions haven't reached that stage. IMHO any company focusing on client lock-in is shooting their own foot.

A more reasonable alternative is to monetize server development. Find a niche or market segment that would b

WTF?

[R2.0]

"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.

New Here

[Chrisq]

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!

Re:

[TheNinjaroach]

That's really cool, we could really use a Twitter-like enjabered XMMP server here. It will revolutionise computing!

Bonus points for spelling the acronym wrong.

Re:

[Alphager]

"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.

Where do you see a verb that used to be a noun?
ejabberd is an XMPP-server (that apache HTTP server -> that ejabberd XMPP server)
"can be used to develop" should be obvious
"a distributed": in this case this means that the network does not have a central server; the administration is distributed among the different XMPP-servers
"Twitter-like system": a system like twitter (twitter.com afaik).

Reading comprehension isn't your strong point, n'est-ce pas?

Re:

[jdray]

I think you meant verbs to nouns, but you've probably realized that by now. I didn't know WTF Twitter was, either, but I use Firefox, and did a double-click, right-click on the word, selected "Search for 'Twitter' in Google," and read the resulting first hit. It's another social networking service, evidently for those who can't stand the idea that everyone in the world won't know what they're up to at any given moment. Yuck.

I'll be curious to see if XMPP makes it into the world of intra-application messa

Re:

[arivanov]

"that ejabberd XMPP server can be used to develop a distributed Twitter-like system."

You mix twat,tit and throw in some dimwit and you get a twit. Do a while (42) {} on it and here is your twitter.

On a more serious note the more obscure parts of the XMPP spec can be read in so many ways that there is always a way to create non-interoperable clients. For example - the thread support which is even in the original RFC is still not implemented in any of the clients (I did a patch for pidgin a while back, it is still sitting in the queue). Same for whiteboarding and many other things. Classi

Re:

[nschubach]

I have a problem with this sentence, but I can't put my finger on why...

"XMPP has been designed since the beginning as an open technology for generalized XML routing."

The best reasoning I have is the use of "has been designed since" ... ? It just sounds wrong.

Re:

[Angostura]

It's a tense problem. I think. the author is using present continuous, where past tense would be more appropriate:

So XMPP was designed from the beginning as an open technology for generalized XML routing."

Better?

Distributed computing and "the cloud"

[MarkEst1973]

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 [enterprise...tterns.com] was very enlightening to me as I thought more about messaging and less about imperative programming.

New technologies like Terracotta [terracotta.org] (for Java) make distribution simple, too. Eve

Thanks Google

[tmalone]

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.

Re:

[rukidding]

Google has also included an XMPP API for developers of Android. They are also suggesting its use. http://code.google.com/android/toolbox/google-apis.html/ [google.com]

PFTLOGCWCUWMUA

[Skippyboy]

Please, for the love of god, can we come up with more useless acronyms?
Ugh!

XMPP is a PITA

[MasterC]

Perhaps it is just the library I've used [jajcus.net] 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 [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:XMPP is a PITA

[Enleth]

That's just this library. For example, the Smack API for Java is literally five lines of actual code to connect, announce the presence, load the roster and send a message. PyXMPP is quite low-level for a Python network library. Try XMPPy, much easier to work with if you need Python.

Re:

[AceJohnny]

Didn't understand how to use the library? The problem is, there are a ton of XMPP libraries out there for every language (the one you used is for javascript) and there must be an unwritten agreement that it's no use for each library to re-explain the workings of XMPP...

The best way, I'm afraid, is to read the RFCs [xmpp.org] (mostly 3920 and 3921. There are updated, clearer drafts, 3920bis and 3921bis, a link away from that page) and XEPs [xmpp.org] (XMPP Extension Proposal). There's also a book [oreilly.com], but I heard that it's a bit outd

Re:

[MasterC]

the one you used is for javascript

What the hell?

http://pyxmpp.jajcus.net/ [jajcus.net]

PyXMPP -- Python Jabber/XMPP implementation

How do you get javascript from that?!?!?!

As for this part:

there must be an unwritten agreement that it's no use for each library to re-explain the workings of XMPP...

I don't need the library to hold my hand and explain XML, the concept of "online" vs. "away", etc. I want a page that says you have to: connect, authenticate, pull down a roster, send presence notifications, and then send messa

Re:

[AceJohnny]

PyXMPP -- Python Jabber/XMPP implementation

How do you get javascript from that?!?!?!

Woops, you're right. I misread /.'s domain shortcut, jajcus, for JSJaC [in-berlin.de].

Regarding doc, I'm didn't mean that you needed to read all the basics down to XML Namespaces or whatever, but I was surprised by your frustration with interacting with XMPP, and interpreted it as a lack of doc for semi-advanced topics. I couldn't believe that PyXMPP wouldn't provide even a basic tutorial on getting online and sending a message. Indeed, I haven't found anything after some quick googling.

As I said, there's a host of libra

Re:

[Jerf]

There are a lot of very crappy (IMHO) libraries that do nothing but wrap the XML and present it to you in some form, leaving it entirely up to you to do, well, everything else.

If you are enough of a programmer to deal with Jabber, which means being comfortable with XML, this is by far the easiest bit of working with Jabber. All the tricky bits like connecting and stuff are the harder bits worth writing a library for.

Look for a library that handles:

• Connecting to a server, with encryption (SSL or STARTTLS up

Re:

[Kent Recal]

No, it's not just you. I was in the same situation (investigated XMPP as a messaging protocol) and didn't find any useful documentation either.
The little bits that I found were either sparse, incomplete, not authorative, outdated or wrong. Often it was *all* of that at the same time.
Even most of the sample implementations and libraries were outright broken.

XMPP sounds like a great idea in theory and the existence of fairly mature implementations (in erlang FWIW) suggest that *someone* must know how to put t

Re:

[Sancho]

XMPP is a simple, if deep protocol. Most libraries implement it at a fairly low level--they don't give you a function which sends a message to a specific jid; instead, they give you functions to create a message packet and send that on. They provide functions to send the IQ and Presence packets, but require that you explicitly do so rather than taking care of that upon connect, and offering functions to let you change your status.

Learning to use the libraries, then, requires reading the protocol specificat

Re:

[Randle_Revar]

Documentation: http://www.xmpp.org/ [xmpp.org]

As far as implementations, there are 3 major Open Source servers: ejabberd (Erlang), OpenFire (aka WildFire, written in Java) and jabberd2 (C), not to mention djabberd, LiveJournal's Perl-based jabber server framework.

Re:

[Just Some Guy]

We use jabber.py [sourceforge.net]. It hasn't changed in years, but our needs are pretty simple and it meets all of them easily. For example

import jabber

node = jabber.Message()
node.setSubject('Getting hungry')
node.setBody('Hi there. Lunch?')

server = jabber.Client('ourserver.example.com')
server.connect()
server.auth('me', 'mypassword', 'Python Jabber client')

for dest in recipients: node.setTo(dest); server.send(node)
server.disconnect()

Honestly, I don't know how you could make that a whole lot simpler.

Re:

[MasterC]

Honestly, I don't know how you could make that a whole lot simpler.

Yeah, that's brilliantly simple. Except when you have no clue what you're doing.

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

Re:

[Just Some Guy]

What I was addressing was that the fault is in the library (or libraries) you've tried, not that writing a client is inherently difficult.

XMPP isn't a big deal, except on a phone

[kerskine]

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.

Re:

[erlehmann]

once i met this guy who encapsulated xmpp into http-requests because his data-flatrate somehow was http-only.

Re:

[Sancho]

There are problems with doing this. First, it means that you're running an additional application on your phone. Second is that to receive notifications, the Jabber client must have an open connection to the server full-time. That's going to be a drain on the battery.

I actually have a smartphone with a Jabber client, and since I primarily use IRC, I wrote some scripts to glue messaging between xmpp-irssi and irc (mostly a gateway between the two so that I could bridge my IRC session to my phone.) The dr

The 'X' means Extensible

[ishmalius]

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

XMPP decentralized online social networking ?!

[erlehmann]

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 [xmpp.org]

Anything can be the next big thing

[drolli]

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.

Let's hope not

[VokinLoksar]

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_ e

Re:

[Sancho]

Likewise, this protocol seems like it was designed for humans

XML is intended to be human readable, presumably for debugging purposes (though possibly also for other reasons.) Making your protocol human-readable doesn't mean that it's a bad protocol--it means that it had goals which apparently differs from yours.

Re:

[thePowerOfGrayskull]

Aw c'mon, it was a JOKE, people! :P