Jabber stands on the brink of becoming a general-purpose mechanism for allowing people, devices, and programs to interact. How will it play with .NET? Jeremie Miller, Jabber's inventor, offers his thoughts.
|PHOTOS © GARY WAGNER |
Jabber began as a way to link ICQ and AOL instant messaging. Now it stands on the brink of becoming a general-purpose mechanism for allowing people, devices, and programs to interact. How will Jabber play with Microsoft’s .NET initiative? What about AOL? Jeremie Miller, Jabber’s inventor, offers his thoughts.
The cornfields of Cascade, Iowa are a long way from Silicon Valley, but this quiet farming community of 2,500 is now headquarters to the development effort behind open source’s most popular instant messaging server: Jabber. Actually, Jabber HQ is a third-generation corn farm just outside of town, where Miller leads the development effort from his home office. Originally written as an XML-based server that could swap instant messages between the proprietary formats of AOL and MSN, Jabber has recently caught the attention of some major corporations — Disney and France Telecom to name two — and in 1999 Miller co-founded a company, Jabber.com, to sell a commercial version of his messaging server.
According to Miller, online chat is only the beginning. The way he sees it, Jabber could be used to swap data between applications and devices as well as people, and that could make it one of open source’s most important applications in the emerging Internet. Robert McMillan and Jeremy Zawodny of Linux Magazine caught up with Miller at the O’Reilly Open Source Convention in July to ask him what Jabber can do and how that makes Microsoft feel.
LINUX MAGAZINE: How did you come to write Jabber?
JEREMIE MILLER:I remember playing with ICQ a couple of months after it hit the streets in 1995 or 1996, and I didn’t know anybody on it, so I dropped it. Then about a year later, people I knew started using it. So I fired it up again. I gradually started having more friends and co-workers using it, and I could use it from home and from work.
Then I had a friend pop up who was on AIM (AOL Instant Messaging). All of a sudden I realized that this was a completely separate network from ICQ, with separate software. I didn’t like AOL anyway. I’ve always thought that AOL makes their users dumb. They’ve got such a dumb interface and they prevent users from accessing anything other than what AOL presents. This seems like a bad thing — users are paying for a simple interface, but there’s nowhere to go from there.
LM: They become captives.
JM: Right. So I never liked AOL. Then I found out that to talk to this user on AIM, I’d have to install AOL software. And over here was ICQ, and they were completely separate domains, which was really frustrating.
At the same time, a couple of friends were playing around with a little Perl script that would send messages back and forth between ICQ and AIM — two clients could connect to it and it would rewrite messages. So I thought, “Well heck, it isn’t that hard to write an instant messaging system.”
LM: Famous last words…
JM:Yeah, I was really into XML at the time. I believe I wrote the third XML parser ever created. So by early 1997, I realized what XML was going to be able to do and I saw where instant messaging was going. I also saw that there were libraries out there where people had reverse-engineered the AIM protocol, the ICQ protocol, and the Yahoo protocol. So I thought, “If I take these libraries and define an XML format that they can all dump into — then someone can build a client that understands this one XML format, and it could talk to all these other services.” In the same instant I realized, “Wait a second, they can talk to each other without going to any of the other networks; you could have your own IM system.”
LM: At what point did Jabber go from being just a bridge between IM systems to a more generalized platform for messaging applications?
JM:For me, I don’t know if it ever really changed. When I looked at the problems of instant messaging and these back-end libraries, I realized there was a more fundamental problem in letting applications talk to each other bi-directionally — unlike HTTP, which is stateless: one connection, you get data back. There are a lot of new applications that need to constantly talk to each other bi-directionally. Maybe they will have a break in the talking, where you’re offline for a while, so there’s the concept of presence involved too. I basically took XML as a starting point and said, “How can I build a system with XML that can do this?” I knew if it passed the acid test, instant messaging, then it could do what other applications needed, because IM is a pretty intensive real-time application.
LM: Really? So you were thinking about more than messaging from the very start?
LM:Has Jabber moved into new spaces that have surprised you?
JM:Not only Jabber, but the software industry itself is moving in directions that are surprising me now, compared to what I thought they would be doing in 1997 or 1998. Web Services are very interesting. A lot of the Voice Over IP stuff and SIP [Session Initiation Protocol] is fascinating. And that’s where Jabber is starting to surpass my vision: integrating Jabber and Web Services and Voice Over IP, having IP phones that might be registering against a Jabber server using SIP, and having your client chat with that person in text that could be translated into voice over a telephone. There are all sorts of really interesting things going on that I couldn’t have envisioned at the time I wrote Jabber.
LM: Has Microsoft talked with you about Jabber?
JM: I haven’t talked with them directly, but from what I’ve heard, they seem very positive about Jabber. They understand what it does and are excited by it — not that they’re doing anything that interoperates with Jabber, but they seem happy it exists and that it’s out there doing this XML stuff.
LM: Is Jabber ultimately competitive with what they’re doing?
JM: They have a huge set of tools and services they’re building into .NET. Jabber duplicates some of what they’re doing, but we don’t have a development environment and a language. It’s not like we’re competition to them. But at the same time, I think what Jabber offers to people who want to do something like .NET in conjunction with other open source projects might be a comparable offering.
One of the things that’s been part of Jabber since the beginning is interoperability. We’ve always interoperated with other IM protocols, even IRC and SMTP. There’s no reason why once .NET is launched and Hailstorm and all the APIs are published that Jabber won’t fully support them, and the traffic might flow smoothly between the two. I’d be ecstatic to have that.
LM:How hard has it been to support all of these different protocols?
JM: We’ve had problems with AOL the whole time. I don’t necessarily deal with those directly myself, as most of the reverse-engineering is done by other open source people, such as GAIM [the GNOME AIM client]. They all use the same reverse-engineering libraries that Jabber uses to talk to the same protocols. Whereas they’re just displaying it to the user, we’re converting it to XML, and then it’s going to the user. So a lot of the problems are solved by the people working on those libraries. Some of those people work with the Jabber stuff as well, so it gets solved for Jabber at the same time. AOL’s the only one that’s been a problem.
LM: Why is that?
JM: Microsoft seems to be somewhat okay with open stuff. They published their protocol — it was really old, not the current one. Yahoo’s always taken a back-seat stance. They don’t mind people reverse-engineering their protocol. Microsoft is very similar. But AOL has always been adamant about not wanting their users’ screen names and their passwords going through any software that’s not controlled by them. It’s an understandable position. I don’t know if it gives them the right to try as hard as they do to block everybody.
LM: What’s been the most frustrating thing that AOL has done?
JM: This spring they started doing network-level blocks against the major Jabber services. And the AIM gateway on Jabber.org and Jabber.com can’t work, not because of a protocol change, but because AOL’s just removing that IP address…
LM: They’ve firewalled it off.
JM: They’ve firewalled the Jabber server off so anyone going through Jabber can’t talk to their site. There’s nothing you can do about that. We can move the Jabber server to another IP address, but usually within hours of doing that, they know and block that IP address.
LM: It’s an arms race at that point.
JM: Yeah, and we were keeping up. We were moving continually for about a month. I had a class C that I could use at one point, and then they figured out how to block the class C. I need a class B. So if you’ve got any class Bs to spare and a Linux box with a shell account…
LM: So what do the Jabber users do when this happens?
JM: Most of the people who really use Jabber have their friends using Jabber as well, and the AIM gateway is more of a utility for seeing a couple of people who aren’t. AIM was just a convenience, so they’re not overly upset.
LM: How many people use Jabber?
JM: That’s like asking how many people use Linux. There’s no remotely accurate way of telling. I think Jabber. com has over 100,000 registrations and about 20,000 or so active users each day. Jabber.org is similar, but more like 80,000 and 10,000 active users. There have been around 70,000 server downloads. You don’t even know how many client downloads there have been, because there’s multiple locations and lots of clients.
LM:Disney is probably the most prominent Jabber user. How did they get involved?
JM: What generally ends up happening with big companies like Disney is that they see the value of instant messaging and basically set up a team to start building their instant messaging stuff — with France Telecom and AT&T this happened too — and the team utterly fails. The clients aren’t too hard to build, but they build an IM server that handles a couple of thousand users, max, and then it just blows up. They end up emulating the complexity and the closed attitude that all of the IM services have, and it just doesn’t work. So they end up coming to Jabber; they see this Jabber thing out there and know it works. It’s an open source project; all the technology’s available; everything is there; other people are doing it. And they can go to Jabber. com and can buy a high-scale version that’s integrated with Oracle and just be done with it. And it’s cheaper than sending your own development team off to build their own server. So that’s where Disney and a couple of the other large customers came from.
LM: What do you think people will be using Jabber for in five years?
JM: In five years…try to think back five years, back to 1996-1995. How much have things changed between now and then? I don’t know if in ’95 anyone could have predicted how the Web is being used nowadays. Maybe if there was a similar evolution of Jabber you would end up having a sort of blurring between the Web and e-mail and Jabber functionality. You’d have a context-aware and identity-aware environment where you’d be able to communicate with other people, other applications, and other services, and it would be delivered — customized to you — and smart agents would be there to help you filter the information. It seems like there’s starting to be a blurring between what e-mail is, what the Web is, and what Jabber is.
LM:Will there be a point to e-mail protocols like POP3 and SMTP then?
JM: Theoretically, with a little bit more work, Jabber can do everything that e-mail does. And with things like BXXP [Blocks eXtensible eXchange Protocol], which is a next-generation HTTP, theoretically, the next generation of the Web and Jabber could be the same thing. Jabber might not become the next generation of the Web — the Web has a way to go to get to the next generation, but there are features of both Jabber and BXXP that could be combined into one fundamental layer.
LM: So what would the next generation of HTTP-type clients look like?
JM: The connection between a Jabber client and a Jabber server is unique in the way the protocol flows over it, and you can’t use HTTP because the server needs to randomly contact the clients and the clients need to contact the server, and that doesn’t go through NATs (Network Address Translation), firewalls, and stuff like that. So the next generation of the HTTP protocol will most likely contain the ability to do any-time conversations back and forth between the client and the server; this will contain enough functionality to just run Jabber over it, so you can have Web traffic, Jabber traffic, and maybe e-mail traffic and other binary traffic all flowing over the same line. That’s a bit of what Microsoft is doing with SOAP and HTTP. There might be independent services running on the same server, but there will be more of a melding on the server side and on the client side — a breaking of the pieces into individual components that are talking via a fabric on both sides.
LM: There’s a great deal of work going on to make Apache 2.0 more of a multi-protocol server. When will mod_jabber come out?
JM: I was going to do it last year when I first heard that Apache 2 would be able to do this, but it was not ready. Some of the Apache APIs were incomplete and unstable, and they were changing some of the filtering in the I/O layers and renaming some things. So I said, “Well, I’ll just wait until it gets closer.” Now it’s close enough that I can start working on it.
LM: Okay, we’ve talked a lot about what Jabber can do. Are there ways in which Jabber has been over-hyped?
JM: I tend to shy away from people who ultimately position Jabber as a Hailstorm competitor because I think Hailstorm and .NET have a much larger scope than Jabber.
LM: So do you think that Hailstorm and .NET will ultimately compete with Jabber?
JM: I think it’s going to be a friendlier relationship. You can go back and look at Microsoft’s track record with Internet stuff, looking at ActiveX and even MSN itself. There are a lot of things that they try and don’t totally succeed in doing. Microsoft is going to succeed at doing a lot, but I think Microsoft will see the utility in having something like Jabber closely interoperate with their stuff, and they will open the protocols enough to let people have that alternative.
If they don’t let people have that alternative, other businesses are going to ultimately become their enemies instead of their customers. It’s true that Jabber might be a threat to Microsoft, but they need those threats to exist. So I think the relationship will be a friendlier one.
LM: But in the past Microsoft has been aggressive in trying to own the APIs that developers write to. Do you see that as a risk with .NET?
JM: It’s always a risk. I think if it really seems apparent that Microsoft is trying to do that, the rest of the business world will be very quick to jump onto an alternative that might be close to Microsoft’s solution. I’m not a businessperson, but from what little I know, businesses tend to be smart about keeping any one company from getting too much control over what they’re doing — especially their data — and that’s what .NET is about. I do not think that it’s reasonable to believe that the companies are going to give up too much data to Microsoft.
If Microsoft starts to own the APIs that channel the data back to them, I would hope that companies would become wary and adopt some of the alternatives, like Jabber, in combination with Mono or DotGNU. If we have support for what Microsoft is doing, it would be a natural upgrade for companies to have all the applications working together in conjunction with what Microsoft is doing.
Robert McMillan is editor at large with Linux Magazine. He can be reached at firstname.lastname@example.org.