Slashdot Mirror
Jabber Could Get An IETF Working Group
21mhz writes: "There is a story on CNET news that provides an analysis of what is happening with
SIP/SIMPLE, AOL protocols and Jabber/XMPP in the IETF. It says that Jabber is close to securing a dedicated IETF working group, in spite of political struggle and corporate maneuvering."
Jabber Central (more pratical information on jabber)
Jabber Powered (an initiative to create products based on Jabber)
Jabber Studio (the development hub of the Jabber community)
Old Jabber documentation
Jabber FAQ
A nice overview of Jabber
Jogger (a jabber based weblog)
Jabber Python module
Unofficial Jabber user guide
Programming Perl(an O'Reilly book)
For those of you who want to try out jabber, psi is a great crossplatform client, with support for windows, linux and mac OSX. I've been using it for some time, and with the msn, icq/aim, etc transports, there isn't really any reason to use anything else.
I really do hope the jabber folks are able to make jabber a standard.
Jabber is, simply put, a universal IM client.
If you use AIM, ICQ, Y!M, or MSN Messenger (or any combination thereof), you can connect to them with Jabber.
It's great if you have, say, family members on AIM, friends on ICQ, and co-workers on MSN.
It also has its own, internal protocol.
However, AIM and Jabber have a history of not working together all that well...so if you have to have AIM connectivity in your IM client, I'd go with Trillian if you use Windows, IMCI for Linux or FreeBSD, or Fire if you use OS X (which doesn't support MSN...but if you're on a Mac, you probably don't need it anyway).
I mod down anyone who uses M$ in their posts. I like to live on the edge.
Jabber is not only the product of one company but the collective effort of many Open Source developers and companies: Jabber servers are available for linux and , and windows.
Clients are available for any platform.
You can choose your preferred server or client and they will work with each other!!
I think you're missing the point though. Yes, Jabber is compatible with AIM, ICQ, Y!M and MSN messenger, but the real purpose of jabber is to establish a standard protocol. Jabber hopes to be to instant messaging what POP3 is to email.
The jabber.org and jabber.com servers have been up for years (not talking about uptime!) with no likelihood that they will ever go away. And those are simply the two most prominent public servers.
I've used Jabber on and off from the beginning and I can safely agree that the user end is a bit rough.
...).
However, here are the reasons you want it:
XML: Now I'm sure by the time this is posted, there will be tons of "XML is the future, adopt it and DESPAIR" posts, but in this case, it is a clear benefit. Bascially, due to XML, the message format allows trivial extension of the protocol. Really, you can just make up an XML element, stick it in the right place and *poof*.
"Is it really this trivial?", you ask. Well, one of my pet projects was writing a Jabber bot for pen/paper RPGs (think Dungeons and Dragons). It took about six hours and I added a element (use the sides property to specify type of dice) that would message you back with a dice roll. I never completely finished the client, but it worked.
Keep in mind all I did to do this was hack two copies of the command-line client--no server changes whatsoever. The key here is that any Jabber server will pass custom XML--so protocol content changes *DO NOT* require server changes and are completely client implementable. Freedom for the masses, anyone?
The possibility of custom clients is huge. Unfortunately, the ability for large companies (AOL, MSFT) to control the state-of-the-art and to make sure that, despite interacting with all IM clients, theirs offers better proprietary functionality on their network (i.e. everyone can message, but AOL partnered with newgame.com so only AOL users can use IM to launch NewGame netgames).
Transparency: This is a big win. It is always possible to pull apart the protocol. Heck, the protocol is designed to be human-readable. This has the added benefit of making obfuscation really obvious (why is AOL using elements named option1, option2, and option3? What is the nsakey element for?
OpenSource: You read Slashdot, you know the pros and cons. The less obvious side of this is how it compares to the corporate offerings--specifically SIP. SIP is great, but try to find a free implementation. If you're using SIP for VoIP (which is pretty much the norm) you probably have had to drop a chunk of change on a nasty Cisco CallManager server.
Loosely Connected: Perhaps the most intelligent Jabber decision was to make it just like e-mail. There's no longer a global hostname, but rather a user@host naming scheme. If you're Internet savvy you can get your e-mail address and jabber address to be the same (exercise left to the reader, think about it).
Existing Gateways: Jabber's weirdest appeal is that it already has gateways to access existing services. The docs have the specifics, but the gateways servers can hit AOL and about everybody else.
Good Standards: Practically all of the corporate offerings are standards that were thrown together (Mirabilis ICQ grew like a Frankenstein's monster, see the procotol specs, they're scary http://www.d.kth.se/~d95-mih/icq/). A ground-up thoughtful implementation like Jabber is a Good Thing(TM) compared to some of the messes.
There are other reasons but I'm tired of typing. You get the idea--Jabber stays crunchy in milk. It's nummy. Get some.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
The allegation that Jabber, Inc. "has patents on stuff you need to implement jabber" is absurd and ill informed. Jabber, Inc. did not even exist when Jabber started, and because Jabber has kept everything in the public eye, and basically put the protocol in the public domain, it's near impossible for Jabber, Inc. to actually own any part of it. Yes, they own the trademark, but as stpeter pointed out it is being transferred to the JSF. It's also true that Jabber, Inc. has many commercial products, but the open source community has something equivalent to most of them.
As to their commitment to the open source community they have people such as myself and stpeter on their payroll that really only work on open source projects and tools. Neither of us have worked on any of the commercial projects in quite a long time.
Jabber-based client application will do something like
[jabber steps omitted]
What I'm trying to figure out is how this is easier, more robust, or otherwise superior to
[tcp socket steps omitted]
It looks to me like pretty much the same set of steps. I'm honestly confused about what the Jabber layer adds, other than xml buzzword compliance. Anyone?
The XML buzzword compliance is actually pretty significant -- not so much for the message content (as you point out, you can send XML with plain old TCP), as for the wrapper. Routing of TCP packets is done at a level way below what most applications can or want to handle; routing of Jabber's XML packets is handled at the application level, and there are standard ways to tell Jabber "routers" (servers) where (what user or service) the packet is to go to. Further, Jabber messages can be stored and forwarded if the destination address isn't currently available. (More like email in this sense).
I think that may be the step you're missing -- the point of Jabber isn't for the client to talk to the server, it's to route through the server to another client (or group of clients).
Because it's XML-based, it is extensible in well-understood ways that any given Jabber-enabled program can safely ignore if it doesn't understand the extension. (But a human might be able to figure out by inspection.)
Protocols are about making it easy for different developers to create programs that will cooperate with each other. Sure, you could create an email system (for example) that used raw RPC calls between client and server, but nobody else would be able to talk to it, at least not without using that same RPC API, which constrains the design. A standard protocol (eg SMTP in this case) simplifies things greatly -- heck, I can send email via telnet to port 25 if I want.
Beyond that (eg your questions about why XML-RPC), well, sure, some of it is just fad or using what tools you already know vs learning a new one. (The "if all you have is a hammer, every problem looks like a nail" syndrome.) On the other hand I've seen pretty fair arguments that XML is just an exotic dialect of LISP, so why not?
-- Alastair