Slashdot Mirror
Programming Jabber
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.
I got really excited about Jabber for the longest time. I'm sort of disappointed in it now, since it seems like they're still having problems connecting to AIM and ICQ. The AIM connection is the most vital for me, since our department uses AIM to send short quick messages to each other. Most of the people here are using AIM's own client, but I started to use Jabber so that I could talk to my friends on ICQ. (And promptly signed up for MSN and Yahoo, so I could catch everyone from everywhere.) Now I use Trillian, which only disappoints me by neither providing source code (which I only want for the principle of it) nor supporting Jabber itself (which does kind of bug me).
While on the topic of Jabber. Why not have the sendmail folks and the jabber folks get togethor and unite their work into a single project. Complete with admin tools so that once someone has a sendmail account on a Unix, they by default have a jabber IM account. It would go a long ways towards taking down AIM, MSN, and ICQ.
I've set up a Jabber box (an early 1.x release) and played about with it, and it was a *very* good experience. Everything worked as advertised. On the other hand, setting up Jabber with SSL was a confusing process without too much documentation and I eventually gave up. Since SSL is a must for `serious' Jabber use, has there been some progress made on making secure Jabber installations easy to achieve?
I read this book looking to use jabber for automated XML messaging and I'll have to say, it has a lot of nifty features that I'd love to use. Unfortunately, it's never getting deployed in my network. Why?
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.
I'm serious. IBM spent a ton of money building MQ-Series, which is a hideously complex messaging protocol for inter-and-intra systems communications in and between mainframe subsystems/LPARs and Unix systems (AIX mostly, since this is IBM, after all).
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.
I've recently been involved in at least two large-scale projects involving developers in three countries, US, Singapore and India. The timescales were very small; we had to implement one of the systems within 48 hours. A huge coding effort it was, with rapid real-time changes to design specs.
/.-ter after all), I just can't de-emphasise how critical MSN Messenger was during development.
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?
Actually, you should check out the smtp transport for jabber....it might provide some of the functionality that you require.
-- Who is the bigger fool? The fool or the fool who follows him? --
Right on! Most avid internetters had been performing Jabber-like tasks years prior to the introduction of ICQ or anything similar, with either SMTP, or IRC or "talk". (The latter two aren't as directly applicable to the problem, though)
I definately remember periods of transmitting emails back & forth at 15 second intervals- this was using "pine", a text-mode emailer that doesn't impose as much GUI-created latency as most email clients.
Its a real same that AOL, Mirabilis, et al, had to create their own new protocols rather than slightly extending SMTP to work in this application. The changes could likely be accomplished with optional extensions, preserving backwards compatibility.
First, POP3 would need a "request push" operation, so that a client could indicate to the server that any new emails within the next 5 minutes should be sent to it immediately. Otherwise, the client would need to query the server every 10 seconds, in order to provide the quick response that IM users want.
Secondly, there should be an optional mail header entry for "instant expiration" priority. Basically a way for the sender to indicate that unless the recipient is online right then, the message can be considered as much less important than ordinary emails. This would just provide a way to segregate traffic by its intended use- client software could ignore it if it wants, although often a different graphical presentation is desirable for IMs vs regular emails. (IMs essentially have only Subject lines, not Bodies)
There's a lot of discussion about how Jabber hackers stopped working toward AIM integration.
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
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
I'll call it and SMTP client. When it connects to the SMTP server it identifies the user and the users IP. The server forwards all messages to this IP. If it's unable to forward it places messages into a mailbox for POP3.
SMTP client first opens POP3 receives mail. Sends ID and IP to SMTP server. Client displays messages and relays messages through SMTP server.
No central server. Your email is your ID. nice and easy. Some detaisl to be worked out.
DRM? No thanks, I'll just get it somewhere else...
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.
What do you mean they cut the power? How can they cut the power, man? They're animals!
You mainly seem to be concerned that since there in a single access point to the system, the whole thing can fail with a single attack on the main server. To a certain extent that's true. The user login data is kept on a jabber server, somewhere, and if that machine fails you lose the ability for certain users to login. I'm not sure if you can replicate user data across several jabberd's (with proper delegation and syncing), but it's probably not hard to implement.
Thank you for your response.
:)
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.
creation science book