Slashdot Log In
Programming Jabber
from the some-people-jabber-naturally dept.
| Programming Jabber | |
| author | D.J. Adams |
| pages | 4555 |
| publisher | O'Reilly |
| rating | 9 |
| reviewer | http://cpfeifer.blogspot.com |
| ISBN | 0596002025 |
| summary | A detailed guide for developers to understanding and extending the Jabber messaging framework. Examples in Perl, Python and Java. |
The Scenario
Jabber was first conceived by Jeremie Miller (pic) in early 1998 in an effort to unify the disparate instant messaging networks. Instant Messaging networks rely on the network effect to gain and retain marketshare. The concept is the same when applied to any sort of participatory network whether it's a junk exchange, or content exchange, the value of the network increases with the square of the number of participants.
If this is true, then doesn't it follow that it is in the best interests of the IM networks to establish peering agreements with each other so that their users can directly contact users on other networks without having to install each client?
Hello, Jabber.
When I first picked up this book, I expected to understand the Jabber protocol in sufficient depth to implement my own IM client. Instead, the approach this book takes is that Jabber isn't just an XML-based protocol strictly for IM, rather it is a general purpose event notification protocol that has some very nice message routing and user management features built into it. While i was reading about the messages that Jabber has defined as part of the protocol, I could easily see other applications/devices generating Jabber messages to notify subscribers (either other systems, or people) of events.
Part 1 of the book focuses on getting you up to speed on the basics of Jabber technology: motivation, major features, XML protocol sample and compiling/configuring your own Jabber server. Chapter 2 presents the "10,000 foot view" of Jabber technology. In here you will find a sample client-query request/response flow with full HTTP headers, discussed step by step. The next two chapters are a very in-depth discussion of installing and configuring your own Jabber server. When you dive into a custom configuration of a fleet of Jabber servers (a "constellation" in Jabber terminology), it really starts to hit home that the real problem Jabber solves is far deeper than just IM.
From there, part 2 kicks off with a detailed discussion of the most basic building blocks of Jabber technology: resource identifiers, XML handling mechanism and the set of XML elements/attributes that make up the vocabulary of the Jabber protocol. Each element/attribute is presented with an annotated example and sample client/server interactions where appropriate. Examples can make or break a technical book, and these examples do a good job of illustrating how the element/attribute is used.
The following chapters take you through using standard Jabber features, user registration/authorization, messages, presence, groupchat, components and the event model to enable new applications. One very interesting application presented is enabling developers to receive CVS commit notifications via Jabber.
What's Bad?
I know the /. community is suspicious of glowing book reviews where everything is wonderful and nothing could be done to improve the book, so I'll nitpick. My major problem with this book is that the overwhelming majority of the sample applications are written in PERL/TK. This isn't a problem in and of itself, but I'm not a PERL/TK developer. If I build a Jabber solution, it will be in java, so PERL/TK samples don't do me a lot of good. I think equal time should be given to implementing Jabber using the two most-used languages, as defined by the number and activity of open source projects using Jabber technology.
What's Good?
This book covers everything relevant to Jabber technology, from lowest level inner workings and extensibility examples for developers to configuration and deployment for admins. Most of the book is spent looking directly at the Jabber XML protocol, instead of a specific API implementation. This way, the book covers the technology and doesn't get lost in how one particular API models the protocol.
So What's In It For Me?
If you want to implement an inside-the-firewall IM solution for your company/group/tribe or investigate integrating event notification into an application, this is a great starting point. If you're just curious about Jabber and want to know how it works, then this will give you enough information to get you hooked.
Table of ContentsPART 1: Getting Started with Jabber
- Chapter 1. Introducing Jabber
- Chapter 2. Inside Jabber
- Chapter 3. Installing the Jabber Server
- Chapter 4. Server Architecture and Configuration
PART 2: Putting Jabber's Concepts to Work
- Chapter 5. Jabber Technology Basics
- Chapter 6. Jabber Namespaces
- Chapter 7. User Registration and Authorization
- Chapter 8. Using Messages and Presence
- Chapter 9. Groupchat, Components, and Event Models
- Chapter 10. Pointers for Further Development
Appendix A. The Jabber.xml Contents
Appendix B. The IQRPC Classes for JabberRPCResponder
Index
O'Reilly has posted other reviews of the book on their site. You can purchase Programming Jabber from bn.com. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
Trend in modern computing (Score:2, Informative)
This is on of the hottest topic for the near-future computing world.
Anyway the SOAP (+WSDL+UDDI, ie: the Web Services) initiative seems much closer to be the real mover in this environment.
Interesting (but not suprisingly), XML is the basic enabling technology for all these efforts.
Jabber (Score:3, Interesting)
Re:Jabber (Score:4, Informative)
YMMV, but it's working for me, plus the cross platform nature means that I'll start recommending it to people who have been using Trillian in the past. It's at the "almost there, but not quite finished" level, with two major bits missing - a total lack of documentation (which can get gotten around), and lack of support for group chat - which means the IRC service won't connect (not to mention AIM group chats). I just discovered it, so I can't say how fast work progresses on the project, but it's very much usable for my needs right now. Sounds like it might work for you, too.
My Jabber ID is JabberWokky@charente.de, and that server supports AIM, ICQ, MSN, YIM, Jabber and IRC.
--
Evan
Jabber and Sendmail (Score:3, Interesting)
Review (Score:1)
Jabber + SSL (Score:4, Interesting)
Prebuilt clinets? (Score:1)
1- fail to get the fundimental concepts (of anything)
2- write hooj crappy code that just loops and burns
3- I have been diagnosed as having an attention span of a small nat.
oh and i would use google to look for some but my companys web access is going a bit screwy at the moment and google has dissapered...
Problems with the sample chapter (Score:1)
My big problem with Jabber... (Score:4, Interesting)
You can't cluster jabber servers. If the main jabber server goes down, you're hosed. In any application that's worth the effort to deploy, having such a single point of failure is a big problem. Additionally, I was kinda annoyed at how jabber leans so much towards instant messaging. I know, I know, that's what it was built for, but this book is trying to pass it off as an "XML messaging" tool, but it's properties often sway back to IM.
In conclusion, if you wanna fool around with a nifty IM robot that doesn't need to be relied on, jabber is a nifty tool. If you wanna do real XML messaging, try something like xmlblaster.
wrong (Score:5, Informative)
one for the main server
one specifically for AIM
one for ICQ
one for MSN
one for yahoo! IM
the four IM trasport servers have their own jabberd process. If a transport server dies (as they occasionally do), you can bring that server back up without affecting any other servers.
But you don't have to break up the servers this way. You could run multiple jabber servers, and place bandwidth restrictions on them so that when a jabber server got "full", it would stop receiving connections, so the jabber server above it in the chain would then forward it on to the next jabber server in the chain, or back up if it's out of children servers.
it's a relatively simple matter to setup an init.d script to monitor the health of all the processes, and restart them when and if they fail. I've been running a jabber server on one of our linux boxes for weeks now, and I haven't had to touch it once. I highly recommend jabber for intranets.
Re:My big problem with Jabber... (Score:4, Informative)
Jabber is an open system/protocol, anyone can build new servers/clients/etc with whatever features and extensions they want, including building it on/with xmlblaster. Jabberd is also an open source project that your welcome to help with (farming/clustering is a frequent need and I suspect that it will be a large part of the jabberd-1.5 development series).
Hey, remember SMTP? (Score:4, Insightful)
people seem to forget that good old SMTP solves many of the same problems, and in fact solves them better.
For example, many years of work have gone into making sure that email never gets lost. SMTP mailers just don't lose email anymore. Jabber messages, on the other hand, are not really reliable. If the user to whom you are targeting a message is not online, the server may queue the messages, but the policy is not clear as to how long they will be stored, or if the server is rquired to store them at all.
This makes me worry about the idea of using Jabber to build infrastructure where you
rely on messages to always be delivered.
It seems to me that many of the issues that Jabber
solves have been solved using existing
technology such as SMTP, and mailer and mailing list services built on top of it, like qmail, mailman, etc.
Jabber (Score:3, Informative)
I've played around with the jabber module in Perl, which was pretty easy to use.
Jabber started to disappoint when they stopped supporting AIM/ICQ. I don't know if it's permanent, I don't actually know if it's still not supported. But, since AIM is what I have to use for work (otherwise, I would still just be using ICQ to talk to my friends), I needed something that could stay connected.
I use Trillian [trillian.cc] now. It still does ICQ/AIM as well as IRC/MSN/Y!, which is why I need something like this, but it doesn't provide source code (which I only really want for the principle of it) and it doesn't support Jabber's protocol. (They're talking about releasing an API for writing plugins. At least it's free (as in beer). (I've got a few of my coworkers switched from AIM to Trillian...) Hopefully Jabber will fix up the connectivity issues (or have ALREADY fixed them up.) gosh, I should download WinJab again and check.
M$ would be proud... (Score:1)
...since this has been the general philosophy of Outlook for years now. This of course has also been the largest single security hole for years now too!
I think I still like being the human middleman, thank you very much!
Value = N-Squared (Score:1)
Where does this intuitively-obvious statement come from? How do we know that it's squared? I believe that it's true in general: that value increases geometrically as N increases. Who has run the numbers on this phenomenon, and where can we go to find descriptions of epiphenomena related to it?
If this is true, then doesn't it follow that it is in the best interests of the IM networks to establish peering agreements with each other so that their users can directly contact users on other networks without having to install each client?
It seems that when people are investing resources (money, effort and time), it's seeing the actual numbers that will convince them. Anybody got references at hand?
I use it every day (Score:2)
Probably the best thing about gabber and myJabber is that they offer encryption. Both can connect to servers using SSL encryption, and gabber has the added bonus of being able to use GPG keys for one to one chats to particular users. This gives me a warm squishy feeling as I communicate over networks that I _know_ are being monitored. The SSL is very nice, because at least I know my communication between the server and myself is at least not totally trivial to break (yes, I know about ettercap). This appears to even affect my aim traffic, as the AIM transport on the server does the actual relaying of messages.
Jabber has a billion other things in it. You should really give it a shot.
Could Jabber replace IBM's MQ-Series? (Score:3, Interesting)
MQ-Series really is complicated, maybe over-complicated, to the point that IBM and customers even have "MQ-Series Specialists" on staff.
I'm not flaming IBM here (h*ll, I used to work for them, and they're a great company to work with), but they do have an unfortunate tendency to build overly complex systems where simpler ones might be a lot easier to use.
Pretty good stuff. (Score:2, Interesting)
As much as I hate M$ (hey, I AM a
Only one problem though:- you'll need intense amounts of concentration to ignore junk messages from friends.
This is one place I'd focus on. You know, perhaps an avatar sort of thing; in your programming (work) avatar, you are online to only a certain people. In your chillout avatar, you are online to everyone. The programming avatar also could have an auto-message feature:- perhaps one that delivers a message to the tester once you finish coding a class or something.
Any open source Jabber-related projects out there working on this?
Jabber : great concept, awful reality. (Score:1, Flamebait)
Problem Number One: The server sucks. Once you start using jabber, you get the joy of watching your client disconnect for no apparent reason, quite regularly.
Problem Number Two: The gateways suck. Jabber has a cool concept where it can provide a gateway to other instant messengers, such as AIM. They crash. A lot. Additionally, you'll find that the jabber gateways can't block senders, so remember that psychopath who is suing the company and you don't want to even know if he's trying to contact you? Too fucking bad, suddenly his messages pop right up.
Problem Number Three: The client sucks. First of all, it crashes (have you noticed a pattern here, yet?), and secondly it has a terrible concept of what should happen to window focus when an incoming message arrives.
Problem Number Four: It's not neccessary. Everybody already has a desk phone, a cell phone and email. Many people also have pagers, wireless email and such. The problem isn't a lack of methods with which to communicate. Adding jabber will not make your company more competitive, reduce costs, improve communication or improve morale.
The moral of the story? Shoot anybody who uses jabber, and you'll save yourself a lot of trouble in the long run.
Jabber message routing (Score:1)
There was a "jabber as middleware" (JAM) intiative going on last year. Not sure if it's still active. My understanding is that it intended to morph jabber into a middleware message router which would have connectivity to the desktop.
What's always confused me about this approach is that there are already plenty of messaging systems out there. It might make more sense to shim a Jabber protocol adapter in front of an existing JMS implementation.
AIM (Score:1, Interesting)
The problem as I see it is that when most developers of these alternative IM clients try to hook into AOL's chat network, they do so the wrong way. AOL has a public protocol, and a private protocal; so, unless you want to worry about spending an hour or two every night working around the latest block that AOL institutes against your illegal hook into their private network, just use the public one that's documented and encouraged by the AOL folks.
So, Jabber people -- get AIM integration working via their public network rather than just dumping the whole thing because you can't hack their private area. The only downside is that users can't view others' away messages, which isn't really that big of a deal (if they're there, you can talk; if not, you'll see they're away but not necessarily why they're AFK).
I say this only because many of the comments so far are along the lines of "I used to use Jabber until AIM stopped working...". I for one would like to use Jabber as well and encourage them to rethink their approach to TOC and OSCAR.
An All-Linux Think Tank > Lycoris Review Part 1 of 2 Is Now Available [monolinux.com]
Re:AIM (Score:4, Informative)
Currently I'm actively working on the AIM-Transport (more information [jabberstudio.org]). and expect to put out a version 0.10 in not too long.
Jabber is a hack (Score:5, Insightful)
Part of the problem stems from the fact that IM software addresses 2 applications at the same time, unnecessarily coupling the implementations. These problems could really be approached separately:
- Learn the IP address associated with a globally-unique username
- Send a text message to the interactive operator of a machine with an IP address
The first problem is the much more interesting one- Jabber & AIM already somewhat solve it, but in an unsatisfactory and poorly extensible way. Better solutions would be based on an extension to the normal DNS system- essentially, you want each human to have a resolvable domain name associated with her. With that in place, InstantMessaging is an easy problem.A person could try to implement "TCP over IM", but it would've been nicer if the systems had been designed for this from the start. Actually, there is a 3rd general-purpose facility that might be needed, for reasons of privacy. There should be a way to send a packet to a "resolvable human name", without knowing the IP address it currently maps through. The (trusted) central server will have to forward packets in both directions. (I think that's how AIM normally operates, except that it doesn't accept generic packets, only AIM-formatted messages).
However, that method doesn't uniformly improve privacy. While it does prevent other users from learning your IP address, it makes it much easier for AOL (or other central server operator) to spy on the contents of your discussions. (You should be using encryption, anyway).
Re:Jabber is a hack (Score:4, Interesting)
You could perhaps claim that the task is really to associate an IP address and TCP/UDP port with a person, but you can only realistically use one service per port (port 80 overloading notwithstanding), so you'd have to say that the identification is solely for IM, and so the solution of the problem isn't really useful outside IM applications.
Or you could instead say that the task is to associate an IP address and TCP/UDP port with a person and a service, but now you've got the problem of identifying all services and handling the dynamic nature of port assignment as users become available/unavailable and declare themselves as participating/not participating in the various services. Not impossible, but hard enough that nobody seems to have solved it yet.
Re:Jabber is a hack (Score:4, Insightful)
4555 pages (Score:1, Funny)
Shhh (Score:1)
If the journos learn that it's a new haven for "HACKERS", where they *gasp* can use encryption, our asses will burn.
Not that hard.. (Score:1)
Dont read the syntax, read the semantics
(May i suggest maybe looking at Dr. Robert Sebastas exellent book "Concepts of programming languages"(isbn: 0-201-38596-1))
Jabber shortcomings - not in the book (Score:5, Informative)
What seems to be a huge issue for Jabber is user profile integration with databases. There seems to be an unsupported mysql hack, but the key is 'unsupported'. If you look in the Jabber mail list archives, every month there's people asking how to do it, but NEVER any answers.
Another great one that doesn't get answered - which the book doesn't address either - is the format of the user XML files. Each user by default has an XML file, and many people would like to create them programatically. There is no definitive resource which explains what's in a file and what isn't, and how to put one together. I've hacked something, and it works, but only after several attemps, and it doesn't *feel* good. I'm hesitant to try to add anything else lest I break what's working.
Jabber.com has a huge vested interest in keeping some of this stuff not in the public knowledgebase, because they charge (comparitively) a LOT of money for their stuff.
Last time I spoke with them the minimum to get started was $16,000. Their package offers a completely rewritten jabber server (better thread handling), Oracle and LDAP connectors, and a good Java applet client.
NO ONE in the open source community has even come close to having a Java applet client that is workable in a practical sense.
So yes, the protocol is open, and free, but there doesn't seem to be much consensus on tools, except from Jabber.com and they cost.
What I think Jabber as an open source project needs to focus on:
* XML user file definition and/or database support for user profiles
* Good applet client
:)
Re:Jabber shortcomings - not in the book (Score:4, Informative)
As far as I know xdb_sql currently lacks a maintainer, but it's open source so maybe someone will pick it up.
The lack of good docs on the user file definition is valid, but at the same time it's not suggested you edit it by hand due to the aggressive cacheing used on it. We're starting a new docs effort right now and I'll make sure this is on the list.
The basic applet that is on sourceforge (here [sourceforge.net]) is focussed on simplicity, but it does work, and I know people have built more off of it.
As to your concerns with Jabber, Inc., I don't know why they would want to keep any of that stuff secret. It's mostly useless to them since their server ships with a different XDB backend and their web client has a different focus than a pure applet approach.
Re:Jabber shortcomings - not in the book (Score:4, Interesting)
The basic applet is just far *too* basic to be of much use to our situation (and I guess many others). For starters, it assumes you want to allow people to create an account on your server - there seems to be no way to shut that off in the client.
The person I spoke with at Jabber.com told me they'd completely rewritten the jabber server to be high-volume capable, but that they wouldn't be releasing that code. Possibly ever, or possibly just much later. It's an investment for them, and they have every reason *to* keep is secret. If it's open, and people could implement it themselves, why would they pay Jabber.com?
I wasn't wanting to edit the user XML files by hand, but create them programmatically for users.
I've see the jdev lists and it looks like most questions get answered, but I'd gone looking and never found an answers on the xml file structure for user files, but many questions about it.
Again, thanks for answering.
Java Oriented Jabber Book (Score:5, Informative)
My main problem with jabber (Score:1)
Well, apart from WinJab being clunky and having memory leaks, etc....
My problem with jabber was that both the ICQ and AIM transports were always broken. Occasionally one would work, but it would usually break in less than an hour!
I hear that they've taken the main server's transports off - can anyone tell me the performance of other servers' transports that I've heard about. How about the best small, simple windows client.
I'm looking for something that starts up immediately, is small, elegant and doesn't vacuum up my memory.
Cheers!
(OT) Inter-Machine Communication (Score:1)
Imagine the possibilities - we could have a global network of computers and other devices that communicate through a common protocol! Oh, wait...
Reminds me of the "TCP over HTTP" April Fool's RFC.
language (Score:2)
assembly and C?
Instant Messenger is a gross mis-representation (Score:1)
I wish people would stop thinking about Jabber as simply an instant messenger, in the same way Microsoft has realised that MSN Messenger isn't simply an instant messenger. The data exchange of
As things move on from static HTTP GETS to dynamic sockets, companies will look for products that can easily push and pull data asynchronously to servers. And Jabber excels at this.
Jabber's modular framework allows for the simple server-side creation and client-side discovery of whatever xml namespaces you'd like for whatever programs you make. As in the book, you can receive CVS commit notifications, stock quote notices or send and receive email with Jabber.
Coincidence (Score:2)
A little over a year ago instant messenger clients were banned "without specific authorization" and were heavily used contraband. Now MSN Messenger is a vital part (and defacto standard) of corporate communications. Unfortunately there is a lot of productivity lost from A) Microsoft's shitty network that doesn't deliver near as many messages as you'd expect, and fails to report errors... and B) lots of information that is generated in impromptu conversations and lost when the chat is done. Then there is also C) the waste of bandwidth and D) the security and privacy issues.
Back in the contraband days I whipped up a quick VB program for our group, and was in the process of converting it to a java applet with direct socket layer communication when MSN Messenger was finally let in.
When the new email came down, I quickly responded with a link to imici.com for a solution and then threw in jabber.org and mentioned it as a free alternative. Any one of the above reasons (A-D) is enough to switch, but maybe not enough to overcome the inertia of MSN un-emoticons.
Jabber : what a pain ! (Score:1)
plus... (Score:2, Interesting)
Trillian, OTOH, while it's a great program (I use it myself) is nothing more than a combined front-end client for the existing IM services. Trillian will not help you when you are in a situation where opening a hole in the firewall for IM traffic is just not feasible (assuming that your networked office has Internet access to begin with, and that is NOT a given in the health care field)
AveryZero
Re:Jabber? What a POS (Score:1)
Re:Jabber? What a POS (Score:1)
There are dozens of clients for you to check out if you don't like a particular one. Trillian is great if you are on Windows but what are you going to do on any other platform?