×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is XMPP the 'Next Big Thing'

CmdrTaco posted more than 6 years ago | from the i-sure-wouldn't-complain dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

162 comments

FROSTY PISS (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22290040)

I'm a troll you slashdot faggots!

Re:FROSTY PISS (-1, Troll)

Anonymous Coward | more than 6 years ago | (#22290184)

Are the mod fags glad that they wasted a mod point, would you like to waste another? LOL, I'm so fucking bored I'm trolling and trash talking slashdot. I need a girlfriend and a job.

buzzwords are my favorite (5, Funny)

User 956 (568564) | more than 6 years ago | (#22290042)

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 (-1, Redundant)

Anonymous Coward | more than 6 years ago | (#22290168)

XMPP has been designed since the beginning as an open Web 2.0 technology for generalized XML routing. However, the idea of an XMPP AJAX-supporting Web 2.0 application server is taking shape and getting supporters. A recent example shows that an ejabberd XMPP server can be used with AJAX to develop a distributed Web 2.0 AJAX-enabled Twitter-like system.

There, fixed that for you :)

Re:buzzwords are my favorite (3, Insightful)

samael (12612) | more than 6 years ago | (#22290236)

Except that XMPP isn't a web technology.

Re:buzzwords are my favorite (0)

Anonymous Coward | more than 6 years ago | (#22290262)

twitter. web 2.0. read the last sentence.

Re:buzzwords are my favorite (2, Insightful)

samael (12612) | more than 6 years ago | (#22290288)

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:buzzwords are my favorite (1, Interesting)

jdray (645332) | more than 6 years ago | (#22290946)

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:buzzwords are my favorite (2, Insightful)

Angostura (703910) | more than 6 years ago | (#22292832)

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

Re:buzzwords are my favorite (4, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#22290422)

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:buzzwords are my favorite (1)

Timothy Brownawell (627747) | more than 6 years ago | (#22290748)

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:buzzwords are my favorite (1)

jdray (645332) | more than 6 years ago | (#22291002)

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?

Re:buzzwords are my favorite (0)

Firehed (942385) | more than 6 years ago | (#22290632)

Sure it is - just not one that uses port 80. As far as I'm concerned, "web technology" encompasses anything that works over the internet, not just stuff that goes to make websites.

Re:buzzwords are my favorite (1, Informative)

Anonymous Coward | more than 6 years ago | (#22292320)

...except that you're ignoring the fact that "Internet" and "Web" are proper nouns, and they stand for discrete ideas. The Internet is the realization of TCP/IP. The Web is a subset of protocols served over the Internet. You use a Web browser, not an Internet browser. The Internet is a worldwide, publicly accessible series of interconnected computer networks that transmit data by packet switching using the standard Internet Protocol (IP). It was created by the US Department of Defense's DARPA agency. World Wide Web: The World Wide Web (commonly shortened to the Web) is a system of interlinked hypertext documents accessed via the Internet. It was created by Tim Berners-Lee.

Field test of XMPP based system (3, Informative)

Sique (173459) | more than 6 years ago | (#22290064)

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.

No (0)

Anonymous Coward | more than 6 years ago | (#22290126)

Next question please

Just what we (didn't) need !! (2, Insightful)

Anonymous Coward | more than 6 years ago | (#22290142)

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:Just what we (didn't) need !! (4, Informative)

Enleth (947766) | more than 6 years ago | (#22291266)

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:Just what we (didn't) need !! (2, Insightful)

Sancho (17056) | more than 6 years ago | (#22292794)

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.

XMPP is OK but would be better if JSON (1)

brunes69 (86786) | more than 6 years ago | (#22293040)

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.

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

great om (18682) | more than 6 years ago | (#22291538)

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 (1)

metamatic (202216) | more than 6 years ago | (#22291710)

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:Just what we (didn't) need !! (1)

Qzukk (229616) | more than 6 years ago | (#22291680)

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:Just what we (didn't) need !! (1, Funny)

Anonymous Coward | more than 6 years ago | (#22291952)

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.

You have just reinvented the flickr API.

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

Bazer (760541) | more than 6 years ago | (#22292030)

I don't know about you but I'm all for replacing SMTP with XMPP. XMPP has almost everything you'd need to get rid of spam: encryption and authorization. Also it would be easy to write a Jabber-SMTP gateway if there isn't one already.

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

Just Some Guy (3352) | more than 6 years ago | (#22292294)

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... (4, Interesting)

abigsmurf (919188) | more than 6 years ago | (#22290148)

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... (5, Funny)

Anonymous Coward | more than 6 years ago | (#22290160)

"ex-em-pee-pee"?

Re:Am I too late... (1)

Chrisq (894406) | more than 6 years ago | (#22290222)

I prefer the slavic czemp.

Re:Am I too late... (1)

jdray (645332) | more than 6 years ago | (#22291090)

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... (4, Informative)

Bogtha (906264) | more than 6 years ago | (#22290224)

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

Re:Am I too late... (1)

Rogerborg (306625) | more than 6 years ago | (#22290286)

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... (4, Informative)

TheRaven64 (641858) | more than 6 years ago | (#22290476)

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... (5, Insightful)

mhall119 (1035984) | more than 6 years ago | (#22290902)

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

Re:Am I too late... (1)

vishbar (862440) | more than 6 years ago | (#22291782)

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... (3, Interesting)

mhall119 (1035984) | more than 6 years ago | (#22291906)

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:Am I too late... (1)

Just Some Guy (3352) | more than 6 years ago | (#22292374)

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?

XMPP as a silver bullet? (4, Interesting)

webword (82711) | more than 6 years ago | (#22290200)

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? (4, Informative)

rindeee (530084) | more than 6 years ago | (#22290490)

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:XMPP as a silver bullet? (1)

TheSkyIsPurple (901118) | more than 6 years ago | (#22290960)

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 imaging it says "document contains a blob of document data".

Re:XMPP as a silver bullet? (1)

Enleth (947766) | more than 6 years ago | (#22291598)

You could say that about any protocol out there, a moot point IMHO. An XMPP-based system *can* be open without any effort, by itself. What you do to it is another matter, but it doesn't really say anything about the protocol itself. Well, it *can* be adapted to carry proprietary information, that's all. Oh, and standardised methods for using e.g. GPG for XMPP message encryption do exist.

Re:XMPP as a silver bullet? (0)

Anonymous Coward | more than 6 years ago | (#22292936)

As a government employee, all I have ever seen at several agencies are Lotus Sametime and MS Live/Office Messenger. I have never seen IRC or XMPP at any agency.

Then again, I avoid DoD since they violate my personal principles. They are however one of the only agencies which can waste the money on this stuff.

Re:XMPP as a silver bullet? (2, Funny)

Tablizer (95088) | more than 6 years ago | (#22293004)

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.
   

Performance (3, Interesting)

ronark (803478) | more than 6 years ago | (#22290242)

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:Performance (3, Informative)

mremond (211755) | more than 6 years ago | (#22290354)

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:Performance (3, Insightful)

rdradar (1110795) | more than 6 years ago | (#22290402)

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 (3, Informative)

samael (12612) | more than 6 years ago | (#22290274)

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.

Re:A brief explanation (3, Interesting)

vga_init (589198) | more than 6 years ago | (#22290848)

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.

A brief implimentation. (0)

Anonymous Coward | more than 6 years ago | (#22291304)

One can even impliment a better Internet (Http) using XMPP.

Re:A brief explanation (2, Interesting)

hitmark (640295) | more than 6 years ago | (#22293024)

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 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:A brief explanation (2, Informative)

wertigon (1204486) | more than 6 years ago | (#22293314)

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:A brief explanation (1)

MtViewGuy (197597) | more than 6 years ago | (#22291578)

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:A brief explanation (1)

Sancho (17056) | more than 6 years ago | (#22293238)

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 gateway) is because they're losing users. If AOL started losing users to Google because more of those people's contacts were using Google, it would make sense to implement XMPP to try to stem the tide. Keep them on AOL clients, they can still talk to Google, everyone's (more or less) happy (and it looks like this is the direction that AOL is going.)

From there, it could go two ways--people from other networks could start defecting to an XMPP-enabled network, thus causing all networks to go XMPP, or the largest of the networks might balk, dividing the userbase. If Microsoft succeeds in buying Yahoo, then they will have a massive network of IM users compared to AOL/Google. They'll integrate Yahoo IM into MSN, and AOL/Google will become a toy network. You'll need an account on MSN/Yahoo to talk to the vast majority of users that use that network, and slowly, MSN will end up the winner.

WTF? (2, Interesting)

R2.0 (532027) | more than 6 years ago | (#22290292)

"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 (3, Funny)

Chrisq (894406) | more than 6 years ago | (#22290432)

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:New Here (1)

TheNinjaroach (878876) | more than 6 years ago | (#22290904)

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:WTF? (1)

bibi-pov (819943) | more than 6 years ago | (#22290548)

I know my grammar sucks sometimes, but I'm pretty sure there is only a single verb in that sentence and it's "to be", I'll even risk gessing it's the conditional form "can be" which was used. So, I don't really think the tag "stopturningnounsintoverbs" is really appropriated in that case...

Re:WTF? (1)

nschubach (922175) | more than 6 years ago | (#22291036)

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:WTF? (1)

d7415 (1068500) | more than 6 years ago | (#22291228)

I think it's the punctuation or sentence structure, at the place you mentioned. i.e.

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

Sounds better to me, anyway.

Re:WTF? (1)

Angostura (703910) | more than 6 years ago | (#22293060)

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?

Re:WTF? (1)

Alphager (957739) | more than 6 years ago | (#22290552)

"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:WTF? (1)

jdray (645332) | more than 6 years ago | (#22291252)

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 messaging for "get crap done" apps rather than the current "waste my time" apps (I can't believe I actually posted this on Slashdot). It seems like it would be useful for distributing blocks of data to app nodes for work (someone tagged the story "grid," so I suppose they agree), or enabling clustering.

Re:WTF? (1)

arivanov (12034) | more than 6 years ago | (#22292470)

"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. Classic XML-ism actually. The spec is so vague that it could have been written by IBM.

Distributed computing and "the cloud" (1)

MarkEst1973 (769601) | more than 6 years ago | (#22290408)

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. 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 [markturansky.com] . 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.

Re:Distributed computing and "the cloud" (1)

mohanbabu (1097817) | more than 6 years ago | (#22292676)

Gridgain http://www.gridgain.com/ [gridgain.com] is another great product with Spring and AOP-based grid computing. We have used it successfully after considering Terracotta, Gigaspaces, etc. It's very easy to use and has integration with ESB Mule. More info : http://www.infoq.com/news/2007/05/gridgain [infoq.com] We are actually considering implementing a chatty client-server communication in XMPP :)

Thanks Google (5, Insightful)

tmalone (534172) | more than 6 years ago | (#22290496)

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.

Water is wet! (0)

Anonymous Coward | more than 6 years ago | (#22290542)

In other news, water is found to STILL be wet!
XMPP has been used for a while now, bit late are we?

Twitter - should anyone read my IM? (1)

polemon (743631) | more than 6 years ago | (#22291080)

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?

XMPP is a PITA (3, Interesting)

MasterC (70492) | more than 6 years ago | (#22291098)

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 (5, Informative)

Enleth (947766) | more than 6 years ago | (#22291458)

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:XMPP is a PITA (1)

mremond (211755) | more than 6 years ago | (#22291756)

You have also a couple of books on Jabber (before it was called XMPP). They are a bit outdated but it can help you a lot.

Re:XMPP is a PITA (2, Informative)

AceJohnny (253840) | more than 6 years ago | (#22291924)

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

Re:XMPP is a PITA (1)

MasterC (70492) | more than 6 years ago | (#22292894)

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 messages. If RFCs are the sole course of using XMPP then you've missed my point completely.

Seriously, if your answer to "I want to send a message via an XMPP library" is to read the RFCs then your library isn't worth using. I'm all for understanding how protocols work ("oooo, presence stanzas have priority levels?!") but when time is money the utility is much more important.

Re:XMPP is a PITA (2, Informative)

Jerf (17166) | more than 6 years ago | (#22292116)

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 upgrade), with just the JID, password, and an optional hostname/ip override
  • Some decent story about how to create an account if login fails
  • Callbacks for message and presence that A: Give you the relevant information about the presence packets and messages in a nice format but also B: gives you direct access to the full XML stanza in case you want to pull other stuff out of it. (In fact, you should always have the XML in some parsed format.)
  • The ability to register callbacks for IQ stuff so that you aren't implementing an event loop yourself. (Bonus points if it integrates with the event loop of your GUI toolkit.) Closures in your language are awesome here.
  • Some code in the library to work with rosters.
  • Some way to extend the library in a principled manner to support other XMPP functionality, since no library is going to have everything.
That's really a bare minimum, IMHO.

Libraries that just give me parsed XML hunks piss me off, but unfortunately this seems to be the standard definition of "an XMPP library". Connecting to a known account and sending a message to a known JID ought to be a two-four line task at most.

Re:XMPP is a PITA (1)

Kent Recal (714863) | more than 6 years ago | (#22292346)

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 things together.
However, the total lack of documentation makes it near impossible for us uninitiated mortals to do anything useful with it...

Re:XMPP is a PITA (1)

Sancho (17056) | more than 6 years ago | (#22293516)

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

Re:XMPP is a PITA (2, Informative)

Just Some Guy (3352) | more than 6 years ago | (#22292586)

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:XMPP is a PITA (2, Interesting)

MasterC (70492) | more than 6 years ago | (#22293264)

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

XMPP isn't a big deal, except on a phone (1)

kerskine (46804) | more than 6 years ago | (#22291120)

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:XMPP isn't a big deal, except on a phone (1)

erlehmann (1045500) | more than 6 years ago | (#22291590)

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

XMPP decentralized online social networking ?! (1)

erlehmann (1045500) | more than 6 years ago | (#22291200)

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 (1)

drolli (522659) | more than 6 years ago | (#22291932)

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 (2, Interesting)

VokinLoksar (1021515) | more than 6 years ago | (#22292160)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...