Follow Slashdot stories on Twitter


Forgot your password?
Programming Books Media Book Reviews IT Technology

Programming Jabber 180

Reader cpfeifer contributes the review below of O'Reilly's Programming Jabber: if your job (or hobby) includes instant messaging in all its glory, Jabber is a free-beer, free-speech framework for setting up instant messaging systems not bound to a single server in the middle. As cpfeifer points out, instant messaging can mean a lot more than popping an on-screen note to your friend in Des Moines -- machines and programs can use a general purpose communication system like this, with no human middleman required.
Programming Jabber
author D.J. Adams
pages 4555
publisher O'Reilly
rating 9
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 Contents

PART 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


O'Reilly has posted other reviews of the book on their site. You can purchase Programming Jabber from Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.

This discussion has been archived. No new comments can be posted.

Programming Jabber

Comments Filter:
  • machines and programs can use a general purpose communication system like this, with no human middleman required.

    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.

    • I think the next step is Web Services combined with some sort of presence protocol to provide the next generation IM or P2P apps.

      I mean, if I have a web services "servent" on my machine it can do a lot, but no one knows where I am. A presence protocol (maybe the one in Jabber) would allow people to know I'm here and the services that I support. After that, SOAP messages can carry all the rest of the communication directly from peer to peer.

      The question is, is there an advantage to having a Jabber server as a communications middleman (maybe caching XML messages like JMS or MQSeries) instead of just providing presence information and allowing the clients to talk among themselves...


  • Jabber (Score:3, Interesting)

    by Sabby ( 1759 ) < minus poet> on Thursday April 11, 2002 @11:10AM (#3323479) Homepage
    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).
    • Jabber's site clearly states that if all you want is being able to chat with your friends in ICQ, Yahoo, AIM, MSN and/or IRC, then Jabber is probably not what you need, and they do indeed recommend trillian as a good choice. If you want a Free alternative, Everybuddy might be worth a look.

      The problems with proprietary IM networks come, precisely, from those networks' desire to remain proprietary. Witness the self-blocking efforts AOL, Microsoft, Yahoo and ICQ perform on each other, which, inevitably, hit free clients designed to connect to those networks. Jabber's transports are no exception; if AOL decides to block MSN Messenger by altering its protocol, we're gonna get hit too.

      Jabber's ability to access other IM networks is to be seen as a "bonus feature", probably not the main reason to use Jabber. Jabber excels at letting an organization (not necessarily a company, but a group of individuals and/or machines) in need of communication, do just that, communicate, using well-documented protocols, Free software, and self-maintained infrastructure. Granted, maintaining a Jabber server is not too easy (but it's not impossible either), but the knowledge that you're not subject to the whims of AOL, Microsoft and whatnot, plus the sheer number of client software available to suit every user's needs (there's TONS of Jabber clients, I settled for Shaolo on Linux and JIM on Windows) make Jabber an intriguing option for those in need of serious communication.

      • AOL actively block clients attempting to be compatible, but I haven't seen Microsoft go out of their way to block clients as far as I can tell. There was a time when Everybuddy was blocked, but I think that was due to a change in protocol, not because they were trying to block anyone out.
    • Re:Jabber (Score:3, Insightful)

      by garcia ( 6573 )
      I couldn't see using AIM to send "quick messages" in the sense you seem to be trying to convey.

      I use a wireless laptop in the living room to play MP3s from the wired computers in the house. I had to delete IM from the computer b/c stupid college students are fucking addicted to it.

      The addiction isn't so much the problem. The poor CPU is only a p133. It can't handle MP3s and IMs. Then the bastards complain that it takes too much time to send messages and to top it off they fight over who gets to send an IM next or see which profile has been updated in the last 4 minutes.

      The people that left college and are now working in the real world sit on AIM all day and chat. My father, 55, sits on AIM all day and chats. My mother, working at a funeral home and a church, doesn't chat only b/c there is no Internet connection? there.

      Jabber (GAIM, Trillian, etc) would complicate this problem furthur by allowing crazy fools who use IRC, MSN, Yahoo, AIM, etc to talk even more and claim it was for good use.

      I say down w/AIM. ;-)

      Just a little half-off-topic humor for Thursday.
    • Re:Jabber (Score:4, Informative)

      by JabberWokky ( 19442 ) <> on Thursday April 11, 2002 @11:57AM (#3323817) Homepage Journal
      FWIW, when I upgraded to KDE 3, I took a look around and decided to play with new software. I had had much the same experience with Jabber, where it just didn't really work well with other IM systems. For the past three days or so, I've been using Psi [], which seems to work quite nicely with Yahoo Messenger and AIM (the latter of which I use quite heavily in both work and socially). It's Qt based, and so it runs on Windows, Linux, OSX and embedded systems, and since it's under the GPL, you can use the Qt free edition. I think there were binaries there for all the platforms.

      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, and that server supports AIM, ICQ, MSN, YIM, Jabber and IRC.


    • If I understand correctly, AOL is the one that is keeping Jabber from connecting. It's not any lack of capability in Jabber. AOL is afraid of a distributed open-source, ad-free alternative to their IM dominance.

      Jabber clients are quite good. The fact that O'Reilly has a book on it means that it's probably robust enough for a production environment.

      Jabber could be right for you if:
      • You're on an Intranet (why send your chat out to the big bad internet),
      • If you have any concerns about a giant corporation monitoring your chat ("All Your Bytes Are Belong To Us"),
      • You want to prevent 'extra-curricular chat' (you can close off the server to just your staff),
      • or if you're paranoid about security (it does SSL).

      Plus, no ads.
    • 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.

      My jabber server has ICQv7 and AIM transports, and also MSN and Yahoo! transports. ICQv7 was a real pain in the ass to set up but is working perfectly. I've never had trouble getting on to the networks and even the "offline messages" that ICQ has had for years works fine now.

      So I dunno, go use your own server or use an open server line for your ICQv7 needs. I really don't know what your trouble with AIM is though. I always thought of AIM as the retarded cousin of ICQ so I never use the transport anymore. (I was using it to get on to the ICQ network when I couldn't get ICQv7 compiled.)

    • Sabby,

      I think you are looking at this all wrong. Jabber was never meant to be a multi-IM solution. While the transport modules that allow you to connect to other services like AIM can be cool, they are for easing Jabber migration only. Do not come to Jabber with the expectation of perfect AIM compatibility for life. And definitely stay away from proprietary IM systems that you were not previously using (in your case, MSN and Yahoo). No need to make yourself more dependent them.

      The reason to use Jabber is to promote it as a standard. The sooner we all switch to Jabber, the sooner the IM war will be over. Then things like transports and Trillian won't even matter.

      My recommendation for you is to use Trillian for all of your proprietary IM needs (but please, please, don't use extra services you weren't already using), and keep a Jabber client around for Jabber-only communication.

  • Jabber and Sendmail (Score:3, Interesting)

    by Anonymous Coward on Thursday April 11, 2002 @11:11AM (#3323487)
    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.
    • by Raleel ( 30913 )
      Check out the smtp transport for jabber...this might provide what your looking for.

      I've thought this would be an excellent idea as well. So much in fact, that I've been looking at encorporating it into my esmith box. It would be great...add an account, they get domain access, windows shares, email, webmail, groups, jabber...a real single point of service (ya, I know...take it out and your screwed...there are ways around that).
  • I think this review [] says it all: "Quite simply, Programming Jabber rocks! When reviewing the book, I often found myself reading along, having a good time and getting excited about Jabber instead of looking to see if something was wrong or missing." --Jeremie Miller, Founder and Lead Developer of Jabber
  • Jabber + SSL (Score:4, Interesting)

    by cygnusx ( 193092 ) on Thursday April 11, 2002 @11:11AM (#3323491) Homepage
    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?
    • Re:Jabber + SSL (Score:3, Informative)

      by cowmix ( 10566 )
      SSL on the server side is a no brainer now.. Most clients also implement SSL too.

      More important, IMHO, many clients support end to end security via PGP/GPG...
    • If you're having problems with the SSL support in Jabber itself, you might want to look at stunnel. Set up stunnel on the server to pipe the Jabber ports to SSL, then set up stunnel on each client and connect to the server through the tunnel. Not the most elegant of solutions, but it works in a pinch. (There's a chance you wouldn't even need to set up stunnel on the clients if the Jabber clients themselves had SSL support built-in.)

  • Are their any pre-built clinet all ready out thier? Please don't tell me to wirte my own, cos i have an amazing ability to:
    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...
    • Look at for a list of clients. There are clients for:

      * Flash (1)
      * Java (6)
      * Linux / Unix (16!)
      * Mac (4)
      * Mozilla (1)
      * Newton (1)
      * that Windows thing (21)

      I believe they even have a gateway for RIM/Blackberry.

      I concur that Jabber rocks.
      • For the record, most of the clients there suck. That's not to say they're all bad, or cast aspersions on the authors. Most of them say 'beta' or 'alpha' or 'version 0.2' - things like that. *MOST* seem to be someone's idea of a programming exercise, and having to wade thru 3-4 clients before finding a decent one isn't a good use of most people's time.

        Gabber, GAIM and Everybuddy are fairly standard, but depending on what distro I'm using, they often crash. GAIM is most stable, usually. Having a perl command line client won't count as a 'prebuilt client' for most people. Likewise an Emacs client, while neato, won't cut it for most people used to AIM/Yahoo!. Konverse sounds nice, but I can't get it to run.

        Under Windows, Winjab and myJabber seem the most solid/stable, but even they have problems. myJabber has some issue with futzing up if the person you're writing to has an 'away' responder on, and so on. There's so many little niggling things wrong with so many of the clients that it's frustrating to recommend this to people. AIM makes it look so damn simple. :)
        • For the record, most of the clients there suck.

          I agree wholeheartedly. When I went from Windows (ICQ99b) to Linux, I grabbed LICQ. Then when v5 ICQ protocol was being refused by the servers I went to Jabber and tried locating a client I could use that didn't pop up windows and didn't just have huge chat windows. In short, I wanted something light and fast and unobtrusive, like LICQ or the OLD Mirabilis client for Win32. I settled on Psi [].

          Psi is small, fast, cross-platform, simple and clean. I LOVE this client. I would strongly urge everyone who is using this client to send Justin a few dollars through his PayPal account to keep him actively developing his client. He responds to bug reports, accepts patches and tries to include feature requests. Open Source done right, I tell you.

  • I experienced some problems when trying to go to the sample chapter 5 of the book. the server gave me a 404 and I did a quick search for the page and had no problems opening it with another link, but at exactly the same address. Maybe the admins check my webbrowsers vars and check if I came from slashdot. For me it works to just copy the adress into another browser window: [] I hope I could help
    • Yeah I biffed the link. O'Reilly's web server is case sensitive so this: 05 . tml

      is not the same as this: 05 . tml

      The correct link is the second one.
  • by mo ( 2873 ) on Thursday April 11, 2002 @11:12AM (#3323498)
    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 believe that jabber has added clustering support to the commercial version (

    • AFAIK, you can't cluster Jabber servers in the sense of lots of Jabber servers virtualized being a load balancer. At least not with the current reference implementation.

      You can distribute the load, with users logging in to different servers and the jabber servers will route messages appropriately.

      So yeah, if one of those servers goes down, the users who login to that server are hosed. Pretty much modelled on SMTP.

    • wrong (Score:5, Informative)

      by Milkman Ken ( 26074 ) on Thursday April 11, 2002 @12:42PM (#3324107) Homepage
      You can very easily cluster jabber servers. In fact, I have five running:

      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.

      • by mo ( 2873 )
        I was looking at jabber for a different purpose. I've heard a lot of hype that you can use Jabber for more than just an IM gateway, and Programming Jabber talks all about this. The task I evaluated it for is more like a message passing system for many automated distributed programs. The problem is that you cannot cluster many jabber servers in a high availiablity way such that one jabberd outage doesn't segment your network. In your example, what happens when the main server running jabberd goes down? What happens to the clients connected to it?
        • Re:wrong (Score:3, Interesting)

          by Milkman Ken ( 26074 )
          either you don't understand how jabberd linking works, or I don't understand what you're trying to do. You can link different jabberd servers in any way you want. If you want a HA, failsafe system, put your jabberd's on different switched subnets in a hypercube pattern, and you can lose several servers or subnets without affecting the network as a whole.

          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.

    • by jeremie ( 257 ) on Thursday April 11, 2002 @01:02PM (#3324221) Homepage
      What your talking about here is a particular implementation of a Jabber server, jabberd [], not Jabber in general (people often confuse this point). You can do some minimal clustering with the jabberd-1.4 series, but probably not the kind of reliability that your looking for or that [] has built into their server.

      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).
  • by hqm ( 49964 ) on Thursday April 11, 2002 @11:13AM (#3323509)
    One thing that confuses me about Jabber is that
    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.
    • by Raleel ( 30913 )
      Actually, you should check out the smtp transport for might provide some of the functionality that you require.
    • 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)
      • by MeNeXT ( 200840 )
        Forget POP3 just extend SMTP.

        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.

        • It might also stop spam. I know in my last post I mention getting rid of POP3 and then I go and include it. Lets say we replcae POP3 with ETRN. SMTP holds the mail until you connect and sends it to you. Since you are directly connected and are receiving the mail at the same time it is being sent an option may be implemented just cookies in Konqueror where you have the option to reject the message. Your client the refuses the mail which bounces right back to the SPAMMER.

          Now if this forces the spammer server to slow down we may hav less spam.

    • Email and Jabber are usually used for different things. Fact of the matter is, for inter-office comms, its just as quick to find the person and tell them as it is to start an email client and wait for the whole process to deliver their message, then wait for them to check mail etc etc. Jabber = *Instant* messaging.
    • Last time I sent messages to an SMTP server, it couldn't even spell "hello" correctly.

      Jabber is very similar to SMTP, but it also provides "presence", the notification that someone is actually logged in on the other end. SMTP is more "fire and forget".

      Probably going to bring us a whole new dimension in online marketing, God forbid.
      • Probably going to bring us a whole new dimension in online marketing, God forbid.

        Actually, designers of anything IPM-like in the recent 5 years are well aware of the spam problem. Jabber, by default, won't accept messages from anyone/anything beyond your roster. The only
        threat I can think of is that servers start sneak text ads inside vital message fields (any extensions can be easily ignored). But then, you can always change a server or roll your own, because the Jabber network is totally open.
    • It seems to me that the essence of these IM applications is that they help people find other their friend's IPs when they change, either by logging on/off ala the modem era or changing computers. This problem has definatly already been solved.
  • Jabber (Score:3, Informative)

    by Sabby ( 1759 ) < minus poet> on Thursday April 11, 2002 @11:13AM (#3323514) Homepage

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

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

      This is not really true. Yes, the aim and icq transports on the main servers (, were taken down. However, if you go to jabberview [], you can see a number of other stable servers that have fully functionaly aim and icq transports running. I've been using for months now, without a single problem.

      I think the issue is that AOL is blocking the specific ip adresses of the major servers. Remember, jabber is also fairly easy to setup locally, running the server and transports right on your box, or setting up an internal server on your network that everyone at work can use, and they can still talk to their friends through the aim transport.
      • Re:Jabber (Score:2, Informative)

        by Temas ( 30015 )
        Correct. I'm the author of the AIM Transport and it's still in active development. I'm actually in the middle of refactoring it as a completely external component (again). The ICQv7-t transport is also in active development on it's sourceforge site. Besides the blocks on some of the larger public servers things are great, just setup your own =)
  • machines and programs can use a general purpose communication system like this, with no human middleman required.

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

  • ...the value of the network increases with the square of the number of participants.

    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?

    • Actually, I don't think N-Squared is exactly the right function- you're really looking for Metcalf's Law. It states that "The value of a product that interoperates with others of its own type increases as the product becomes more common". This applies to telephones, ethernet cards, internet accounts, and even software like Microsoft Word. It was put forth by the inventor of ethernet in his graduate thesis. For a long overview of the maths, see ry_gi lder.article

      PS. Some texts will print "Gate's Corrolary" beneath the entry for Metcalf's Law. "If the product is software controlled by a single provider, the provider can discontinue interoperability with prior versions to force all existing users to purchase new products, indefinately"
  • I have a lot fo friends on different IM systems. Mostly it's AIM, but some on ICQ, Yahoo, and MSN. I use gabber as my primary linux IM client, and myJabber for windows.

    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.

  • by s390 ( 33540 ) on Thursday April 11, 2002 @11:21AM (#3323571) Homepage
    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.

    • Once I read the review, this was my exact question. However, it doesn't seem that Jabber has the promise of not loosing messages that persistant queue's in MQ can give you.

      Soneone correct me if I'm wrong.

      The promise not to loose a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).

      • The promise not to loose [sic] a message is of monumental importance... and the ability to run on almost all platforms under the sun is MQ's bread and butter (zOS to NT, SCO to MVS).

        But couldn't Jabber do that too? I realize that the public Jabber servers (, might be lossy, but an internal Jabber service might be very reliable, and might even talk to MQ-Series on mainframes (zSeries), Unix (pSeries), and Intel (eSeries) systems. Has anyone tried this? I'm not trolling here, as I'd really like to hear what's been tried and what's maybe possible.

        • There is talk about guaranteed msging in the future , primarily with a focus on JAM (Jabber as Middleware). A lot of this is in parallel with the next generation discussions that are happening on and off. So it is in our sites, but we're not sure how quickly it will arrive. Feel free to join our standards-jig mailing list (See our lists []) and participate, few views are always welcome.
        • This is interesting, particularly since the middleware area is full of so much BS and vendor lock-in.

          I'd like to see if it's possible to wedge Jabber protocol adaptors in front of existing messaging systems. So the existing messaging layer could handle routing and Jabber provides the protocol definition.

          From a portability perspective I'd look at JMS-compliance instead of MQ specifically. There are a lot of JMS implementations, including some open source ones (OpenJMS, Joram, Object Cube).

    • Jabber, as I see it, comes from the other end of the KISS scale. So, the appropriate outcome would be wide adoption among hordes of enthusiasts, not insanely expensive set-top "messaging servers" that require insanely expensive admin spetsnaz.

      More vital question is, whether the IMPP protocol suite, which is being churned out by IETF, can supplant Jabber-based communications. Judging by the committee's pace, they are going to be too late to become the de-facto.
      • (Note to self: use "insanely expensive admin spetsnaz" at next staff meeting. :)

        Yeah, I think the IETF effort is "too little too late". The IMUnified effort is apparently dead as well, since the last press release on their website is from mid-2000.

        Is it just me, or does it look like none of the big mass-market IM players (AOL, MSN, Yahoo) really want an interoperable IM protocol? AIM has the market share, so they don't want to change anything. MSN has a desktop monopoly and want to do to AIM what they did to Netscape. Yahoo probably thinks they have a chance to dominate with a proprietary protocol if AIM and MSN can just tear each other to shreds...

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

    As much as I hate M$ (hey, I AM a /.-ter after all), I just can't de-emphasise how critical MSN Messenger was during development.

    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?
    • by CaseyB ( 1105 )
      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

      More complex event handling in general, yeah. It'd be nice to have a generalized, maybe scripted, event handlers.

      "When (user in group "family") (logs in) (after 5:00 pm), (play ring.wav)".

      "When (Joe) (changes status to (idle) (between 9am and 5pm)) send msg to joe: 'Get to work!!'".

    • How about creating two accounts? I know it doesn't solve the problem perfekt, but it works with all IM today :)
  • Jabber seems like such a good idea at first, you may find somebody in your corporation saying 'hey, let's run a jabber server internally instead of using desk phones, cell phones, email or our shoes.' Let me be very clear about this, if somebody says this, even if they make it sound good, they should be fired on the spot.

    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.

    • I think that you're exaggerating -- my client, Psi, never crashes, and I almost never get disconnected from the server, although it has happened once or twice to me, after I was idle the whole night.

      It's my opinion that running Jabber in a company is a great idea -- it organized properly and good clients are chosen, it could be a godsend.
    • I wish there was a way to find out who made a certain moderation, and send a guy named Guido to their house to find out why they did so. Preferably in one click.
    • You must have been doing something wrong, i leave my client running for days and it NEVER disconnects. Also - id like to know how the server sucks? did you write it? Maybe you should buy the book so you can understand Jabber better, because it sounds like your talking about ICQ, which really gets up my arse.
    • Problem Number One: The server sucks.

      Feel free to write your own. The protocol is completely open and documented.

      Problem Number Two: The gateways suck

      Feel free to write your own. The Jabber protocol is completely open and documented. The other IM networks you'll have to reverse engineer for yourself. This is not a jabber problem.

      Problem Number Four: It's not neccessary.

      In this case, fax machines aren't necessary because we already have the post office. EMail isn't necessary because we have phones. Phones aren't necessary because we have the post office.

      Ah the sweet smell of progress.
    • I'd mod you as flamebait, but it looks like someone else already did. Quit spewing FUD.

      I've set up a Jabber server over 6 months ago and I'm using a client called Psi []. I regularly connect to the MSN and ICQ networks through my server. I have not experienced one problem, much less the disaster you predict.

      I prefer Jabber to the mess of carrying a cellphone, pager, checking email and the office phone. Yes I have them all but I only carry the cel/pager when necessary. I tell people to use Jabber or email if the need to get in touch with me, since telco charges are expensive and I'm not likely to be at the office anyway. My email client isn't always open but my IM is. Jabber is excellent for tying things together.

      In a similar vein, if someone were to suggest to me firing anyone who suggested Jabber I'd end up firing them for being so small-minded. I've far less use for a person who won't consider new technologies than someone who is constantly on the lookout for the next best thing. Then again I'm the network admin for this company, so what do I know?

    • Problem Number One: The server sucks.

      Yeah. Just like the server for the web. What's that you say? There are different servers for the web? Ah, must be like Jabber. There's a nice open source jabberd, a commercial Jabber server, one integrated into Oracle, and hey, look! An RFC for standards, just like the web.

      But the web, as a concept, sucks because "the web server sucks".

      Problem Number Two: The gateways suck.

      I must say, I've only been using Jabber for a few weeks, but the gateways on the server I use ( seem to be perfectly stable. I have greater uptime than Trillian users, and the one time I thought the AIM gateway had problems, two users using the "real" windows AIM client were also booted. I'd say the gateways are at least as stable as the servers themselves.

      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.

      Um. No. Incorrect. You can block messages, or you can use advanced presence to appear logged off to certain users or all users. Your perception of that incorrect "fact" leads us to...

      Problem Number Three: The client sucks.

      The client. *The* client. Ya know, the client for the web sucks too. I wish there was some choice in the matter. Unfortunatly, Mosaic keep screashing on me, and I can't get it to use Java. (You do realize that there are a dozen or more clients to choose from, yes?)

      Problem Number Four: It's not neccessary.

      I'll agree with you there. However, it's a unifying messaging protocol that binds together eveything from SMS to email to AIM to server alerts with intelligent routing, prioritizing and placing it into very scriptable XML documents.

      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.

      Ah, but the idea behind Jabber is to unify all those things. To provide a standard of messaging, so you don't have to check 3 voice mail boxes, 6 text interfaces (email, pager, SMS phone, AIM, intranet), and so on - plus you don't have to worry about numbers or addresses changing. You can globally manage all your communications, and use a single check point, and hopefully eventually wean down your contact points at your lesure.

      Evan The moral of the story? Shoot anybody who uses jabber, and you'll save yourself a lot of trouble in the long run.

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

    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)

    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 []
    • Re:AIM (Score:4, Informative)

      by Temas ( 30015 ) on Thursday April 11, 2002 @01:53PM (#3324550) Homepage
      I beg to differ. I develop the AIM Transport. I've also worked on libfaim, and was around for the initial introduction of TOC. TOC looked promising despite it's odd ASCII protocol, but we continued work on OSCAR because TOC was considered a side project and not 100% supported by AOL. As luck would have it AOL has proved that decision to be wise many times. They have stopped work on TOC numerous times and have even removed features from it. OSCAR has continued to grow. When AOL started to try and block us (Jabber) we grew fairly confident that their changes were directed solely at Jabber. The blocks always happened after minute changes I made in the aim source specifically, and we were told so in an indirect way. Some ended up affecting other libfaim based projects such as Gaim. Until everything was figured out I was heavily considering a TOC implementation. The problem was that would have caused problems for other programs using TOC if they continued to actively target Jabber. I decided this type of behaivour would be unfair to the other projects, and it continues to allow them to always have a "pure" channel. In the end it has all worked out. We have fully figured out their attempted blocks and everything seems to be moving forward. There are specific IP blocks on some of the larger Jabber servers, but that's life.

      Currently I'm actively working on the AIM-Transport (more information []). and expect to put out a version 0.10 in not too long.
  • Jabber is a hack (Score:5, Insightful)

    by ProfessorPuke ( 318074 ) on Thursday April 11, 2002 @11:37AM (#3323692)
    As are all "Instant Message" programs. They are a poorly-designed, short-sighted solution to a problem that should've been addressed elsewhere in the internet architecture.

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

    • I've always wondered why we don't just switch the internet over to IPv6 and give each human on the planet their own address.
    • Re:Jabber is a hack (Score:4, Interesting)

      by devnullkac ( 223246 ) on Thursday April 11, 2002 @12:39PM (#3324091) Homepage
      Learn the IP address associated with a globally-unique username
      Unfortunately, the user identification problem is complicated by the fact that there may be more than one person using a given IP address. Firewalls which implement NAT and servers which have multiple simultaneous logins are quite common and give this complication real teeth.

      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.
    • by Temas ( 30015 ) on Thursday April 11, 2002 @12:44PM (#3324118) Homepage
      I think you're failing to grasp some of the points of Jabber [] messaging, especially as something more than basic chat. The idea (at least from the Jabber [] point of view) is to _NOT_ learn the IP address of the other party. You only reference them from their "username". Username is the wrong term though, we user the term JID (Jabber [] id). The JID format is: username@host/resource. So it is built upon a DNS like system. Once you know another users JID you can interact with it using messaging, presence, or other methods. The power of not trying to interact with an IP directly is it's ability to more cleanly go around firewalls. The client makes a connection outside of the firewall to their Jabber [] server (potentially through some proxy), and they are then on the entire Jabber [] network. Applications that are exposed on the network then have the ability to interactively use presence and a clear path to the user for more complete interaction. So perhaps you are looking at this from the wrong viewpoint?
      • Maybe so. I didn't mean to be so negative, I've been wanting to add Jabber support to my own software. I was unfairly lumping it together with AIM, ICQ, and MSN (to the general public, all instant messengers are the same program with different colored icons).

        One problem I have is that, as an external optimist, I assume that "IPv6 is right around the corner". That would mean that no one ever needs to use NAT again, and that a single computer can have multiple IP address for all of its users (or other purposes). And we already have a DNS system to provide mappings from human-readable strings to software-usable network addresses. I feel a little bad (and dubious) about seeing someone try to reimplement that, even if it is the surest way to ensure that the existing DNS features don't get broken.

        The final concern I have with this Jabber approach is that its a complete layer above TCP- applications are written to the Jabber API and don't even know that TCP is involved. That's a good thing from the perspective of modularity and OSI-style layering, but bad in terms of evolutionary adoption. Existing software is written for the "static web", and that's where corporate money is going to focus future developement. Without a way to gradually shoehorn into popular internet applications, Jabber support may remain a hobby for open-source outcasts, and not benefit the majority of users.

        As a transitionary step, someone could write (maybe someone already did?) a Jabber utility that behaves like a combination of DNS lookup and RPC portmapping- providing a ip address/portnumber in response to a JID string. Many applications could utilize something like that by adding just a few lines after their "hostname()" calls.

        Two use cases where evolutionary Jabber ID support could be valuable:

        • I'd love to read someone a "JID/filename" URI over a telephone, and have him type it into Mozilla/Konqueror/Internet Explorer and pop up a file I've selected to share from my workstation, without having to play around with "Dynamic DNS" services (which are unreliable, expensive, and an even worse hack).
        • Groups of video-game players ("Clans", they were called, back when Quake came out) should be able to create a server for their own use, and get into it by supplying the server admin's JID into their client software. The gameplay can't afford the overhead of Jabber messages (or even TCP) slowing up the running & shooting, so there should only be a brief burst of Jabber traffic at startup to bootstrap UDP communications. (That's an automation of what today's players do over AIM messages).

          John Carmack is friendly to free software- when the inevitable Quake4 developement starts up, someone should offer him a simple Jabber interface as an optional way for players to connect to servers, instead of the corporate Gamespy / MSG Gaming Zone options that you see today.

        (Now, if only I knew a way to mix freenet into this equation...)

    • Extending DNS won't work, because DNS is designed for naming things that don't move around much. Finding a person requires a different design because, if you wait a day to propagate the information of where I'm sitting, it will always be wrong. What you need is a system where my name determines the only machine you ask to get my location, and that machine tells you how to reach me. Standard DNS won't work, because it expects to cache the IP addresses locally or at intermediate points.

      Problem one is actually more general: given a globally-unique username, find out (in a machine-readable way) a piece of information about the user. At the same time, given your own password (or whatever), securely set a piece of information about you (also in a way that can be automatic). For privacy, you may want to demand some authentication in order to provide some sorts of information.

      Problem two is then: specify a piece of information such that it will suffice from getting a text message to a person that piece of information is associated with.
    • You don't seem to know very much about the Jabber infrastructure.

      The Jabber system depends on the routing of messages -- more or less the same way SMTP works, users are identified by a flexible user@host path syntax, except Jabber doesn't (afaik!) have the equivalent of the MX name server record. When I send a message to, it first goes to my own Jabber server,, which forwards it to A message can be forwarded multiple times if multiple layers of servers are involved, such as with external/internal servers or gateways. Jabber can be gatewayed to/from SMTP and other systems, indeed a lot of people, me included, use Jabber to access the AIM, ICQ, MSN and Yahoo! networks.

      There is no central/global user name space because it is unnecessarily complex. It's a decentralized system that does separate the two concerns you list.

    • As are all "Instant Message" programs. They are a poorly-designed, short-sighted solution to a problem that should've been addressed elsewhere in the internet architecture.

      You are correct, but it's a limitation of TCP/IP, which is very much a "lowest common denominator" protocol. The NETMBX feature of DECnet on VMS, in which nodes, processes and users are all principals is the most-correct solution I have found. Exactly the same protocol and API are used whether you want to to IPC between processes, instant messaging between users or any combination of the two, for example notification of status of a running process, or sending instructions. No need to worry about RPC, talkd, sockets and SMTP, etc.
  • 4555 pages (Score:1, Funny)

    by Anonymous Coward
  • by 21mhz ( 443080 )
    Please, everyone, don't tell CNN about Jabber.
    If the journos learn that it's a new haven for "HACKERS", where they *gasp* can use encryption, our asses will burn.
  • If I build a Jabber solution, it will be in java, so PERL/TK samples don't do me a lot of good

    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))
  • by mgkimsal2 ( 200677 ) on Thursday April 11, 2002 @12:37PM (#3324078) Homepage
    The book, from what I read of it (not 100% - maybe 60%) is handy, but didn't tell me much beyond the jabber documentation already out there.

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

    • by Temas ( 30015 ) on Thursday April 11, 2002 @01:31PM (#3324429) Homepage
      I like to make sure that all questions asked on our ( jdev and jadmin mailing lists get answered. Sometimes the questions will get answered in our groupchat, or in other ways, but an answer is usually given.

      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 []) 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.
      • by mgkimsal2 ( 200677 ) on Thursday April 11, 2002 @04:03PM (#3325508) Homepage
        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 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

        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. :)
    • 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.

      Screw MySQL; I want to see LDAP integration! That would rock muh sox.

  • by Temas ( 30015 ) on Thursday April 11, 2002 @12:54PM (#3324162) Homepage
    I've seen a lot of comments disliking the abundance of Perl/Tk usage in DJ's book. Recently Manning Publications [] released Instant Messaging in JAVA: The Jabber Protocols [] in print and ebook. It was written by Iain Shigeoka, and is ISBN 1-930110-46-4. It's a good read and goes over the creation of both a client and a basic server in Java, plus a good deal more.
  • I used jabber extensively for a while about a year and a half to a year ago. Only on my Windows partition, however.

    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.


  • machines and programs can use a general purpose communication system like this, with no human middleman required

    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.
  • "I think equal time should be given to implementing Jabber using the two most-used languages, "

    assembly and C?
  • just yesterday the security bigwigs at the corp i work at sent down a draconian letter about instant messenger programs wasting bandwidth, and more importantly, exposing proprietary information on the internet.

    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 for a solution and then threw in 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.

You don't have to know how the computer works, just how to work the computer.