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