Programming Jabber

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.

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

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

[alapalaya (561911)]

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.

Jabber

[Sabby (1759)]

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 [trillian.cc], 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: much more than just IM

[Roadmaster (96317)]

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.

Re:Jabber

[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

[JabberWokky (19442)]

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 [affinix.com], 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 [e-mail], and that server supports AIM, ICQ, MSN, YIM, Jabber and IRC.

--
Evan

Jabber and Sendmail

[Anonymous Coward]

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.

Re:Jabber and Sendmail

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

Jabber + SSL

[cygnusx (193092)]

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

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

My big problem with Jabber...

[mo (2873)]

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.

Re:My big problem with Jabber...

[gUmbi (95629)]

I believe that jabber has added clustering support to the commercial version (http://www.jabber.com/products/platform.shtml)

Jason.

wrong

[Milkman Ken (26074)]

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.

Re:wrong

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

Re:My big problem with Jabber...

[jeremie (257)]

What your talking about here is a particular implementation of a Jabber server, jabberd [jabberstudio.org], 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 jabber.com [jabber.com] 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).

Hey, remember SMTP?

[hqm (49964)]

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.

Re:Hey, remember SMTP?

[Raleel (30913)]

Actually, you should check out the smtp transport for jabber....it might provide some of the functionality that you require.

Re:Hey, remember SMTP?

[ProfessorPuke (318074)]

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)

Re:Hey, remember SMTP?

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

Re:Hey, remember SMTP?

[MeNeXT (200840)]

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.

Re:IM ~ UDP

[MarkusQ (450076)]

Jabber, AIM, MSN, and others use TCP. In fact, the only client I know of that ever used UDP was ICQ, but that was an older protocol that is no longer being used

I think his point was that Jabber is like UDP in that you aren't sure that any particular message will get through, but then you don't pay the overhead of making sure.

-- MarkusQ

Jabber

[Sabby (1759)]

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.

Re:Jabber

[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 =)

I use it every day

[Raleel (30913)]

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.

Could Jabber replace IBM's MQ-Series?

[s390 (33540)]

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.

Re:Could Jabber replace IBM's MQ-Series?

[Zapman (2662)]

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

Re:Could Jabber replace IBM's MQ-Series?

[s390 (33540)]

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 (jabber.com, jabber.org) 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.

Re:Could Jabber replace IBM's MQ-Series?

[Temas (30015)]

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 [jabber.org]) and participate, few views are always welcome.

Re:Could Jabber replace IBM's MQ-Series?

[s390 (33540)]

Feel free to join our standards-jig mailing list (See our lists [jabber.org]) and participate, few views are always welcome.

ROFL... We'll assume you meant to say _new_ views, etc. (37337ist Open Source hackers!) Thanks for your kind invitation.

Re:Could Jabber replace IBM's MQ-Series?

[21mhz (443080)]

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.

Pretty good stuff.

[The Purple Wizard (537794)]

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?

Re:Pretty good stuff.

[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!!'".

Jabber is a hack

[ProfessorPuke (318074)]

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

IPv6

[Ilan Volow (539597)]

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

[devnullkac (223246)]

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.

Re:Jabber is a hack

[Temas (30015)]

I think you're failing to grasp some of the points of Jabber [jabber.org] messaging, especially as something more than basic chat. The idea (at least from the Jabber [jabber.org] 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 [jabber.org] 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 [jabber.org] server (potentially through some proxy), and they are then on the entire Jabber [jabber.org] 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?

Re:Jabber is a hack

[ProfessorPuke (318074)]

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

Re:Jabber is a hack

[iabervon (1971)]

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.

Jabber shortcomings - not in the book

[mgkimsal2 (200677)]

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.

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

[Temas (30015)]

I like to make sure that all questions asked on our (jabber.org) 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 [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

[mgkimsal2 (200677)]

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

Java Oriented Jabber Book

[Temas (30015)]

I've seen a lot of comments disliking the abundance of Perl/Tk usage in DJ's book. Recently Manning Publications [manning.com] released Instant Messaging in JAVA: The Jabber Protocols [manning.com] 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.

language

[geekoid (135745)]

"I think equal time should be given to implementing Jabber using the two most-used languages, "

assembly and C?

Re:Jabber : great concept, awful reality.

[mosch (204)]

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.

Re:Jabber : great concept, awful reality.

[tzanger (1575)]

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

Re:Value = N-Squared

[ProfessorPuke (318074)]

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
http://www.eff.org/Net_culture/ethernet_histo 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"

plus...

[Avery_Zero (544068)]

Jabber is not just an IM client, it's also the server/protocol. Thus you can implement an IM solution where it would otherwise be impractical or pose a security hazard. I work for a medical firm, and the security issues with sending patient/sensitive information over a third-party IM network are enough to give people nightmares. They don't scare me, though. cause it's something that I would NEVER EVER allow to happen in my network.

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:Problems with the sample chapter

[cpfeifer (20941)]

Yeah I biffed the link. O'Reilly's web server is case sensitive so this:

http://www.oreilly.com/catalog/Jabber/chapter/ch 05 . tml

is not the same as this:

http://www.oreilly.com/catalog/jabber/chapter/ch 05 . tml

The correct link is the second one.

Re:4555 pages

[Big Sean O (317186)]

It also contains the NYC Phonebook...

In 18-pt type.

Re:Prebuilt clinets?

[mgkimsal2 (200677)]

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

Re:AIM

[Temas (30015)]

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 [jabberstudio.org]). and expect to put out a version 0.10 in not too long.