Slashdot Mirror

At the risk of being modded down into oblivion I will say that your question touches on one of the very reasons that the now almost defunct jabberdoc.org saw such great demise. Despite pleas from the Jabber community to release JabberDoc under the Creative Commons, the JabberDoc team decided to go with the GNU Free Documentation License instead. This led to many restrictive policies as well as bureaucratic confusion. You can read more about it on old Jabber mailing lists.

Obviously, there was a lot to be learned here, but it is really just a matter of using the right tool for the right job, and in many cases the GNU Free Documentation License is not the right tool for certain jobs. Even RMS himself stated this when first interviewed on the scope of the license.

No, sadly. :-(.

I don't understand why they won't do it, as this is the reason I use Jabber for IM.

True, I can't drop AIM just yet, but the number of important people in my life who are using Jabber continues to increase. If you don't use open protocols, they'll never have a reason to either.

Don't forget you can use XMPP as a transport for basically anything, and this WS-thing is certainly no exception. There is even an experimental JEP on transporting SOAP over Jabber.

I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.

The bulk of the discussion we had about framing Thes links constitute the bulk of the discussion we had about framing a couple of years ago:

http://mail.jabber.org/pipermail/standards-jig/200 2-January/000201.html
http://mail.jabber.org/pipermail/standards-jig/200 2-February/000215.html

A good summary of the discussion is here:

Basically, the simple framing we were considering (for backwards-compatibility reasons) might have made implementations easier under certain circumstances but also introduced issues (misframing).

How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?

As it stands, its quite straightforward to design a high-performance Jabber server that can handle many connections. Several folks (including myself) have done it.

Most implementations use an off-the-shelf callback-based XML parser (eg Expat or a SAX-based parser). When you get a read event on a connection, you read as much is there, and feed it into the parser. The parser fires callbacks, and you process the data contained in the XML. This all runs out of a normal descriptor readiness loop (select(), poll(), that sort of thing).

CPU time is kept as minimal is possible. We are parsing XML, so its always going to take a little more effort than a binary protocol (though modern parsers are pretty efficient, and there's ways to improve it if we're willing to write a custom parser that binds tightly to the network layer - zero-copy tricks, etc).

On the memory side, Expat in particular is pretty efficient - once its finished with an element, it gets cleaned up. So while its idling, the only state its holding is the top element and its namespaces.

Obviously, there's all the other session state thats being held for the connection (and the user attached to it), but this is unrelated to framing.

So a XMPP server implementation is no better or worse performance-wise than any other type of network server. Its constructed using the same principles, and suffers the same issues.

I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.

The bulk of the discussion we had about framing Thes links constitute the bulk of the discussion we had about framing a couple of years ago:

http://mail.jabber.org/pipermail/standards-jig/200 2-January/000201.html
http://mail.jabber.org/pipermail/standards-jig/200 2-February/000215.html

A good summary of the discussion is here:

Basically, the simple framing we were considering (for backwards-compatibility reasons) might have made implementations easier under certain circumstances but also introduced issues (misframing).

How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?

As it stands, its quite straightforward to design a high-performance Jabber server that can handle many connections. Several folks (including myself) have done it.

Most implementations use an off-the-shelf callback-based XML parser (eg Expat or a SAX-based parser). When you get a read event on a connection, you read as much is there, and feed it into the parser. The parser fires callbacks, and you process the data contained in the XML. This all runs out of a normal descriptor readiness loop (select(), poll(), that sort of thing).

CPU time is kept as minimal is possible. We are parsing XML, so its always going to take a little more effort than a binary protocol (though modern parsers are pretty efficient, and there's ways to improve it if we're willing to write a custom parser that binds tightly to the network layer - zero-copy tricks, etc).

On the memory side, Expat in particular is pretty efficient - once its finished with an element, it gets cleaned up. So while its idling, the only state its holding is the top element and its namespaces.

Obviously, there's all the other session state thats being held for the connection (and the user attached to it), but this is unrelated to framing.

So a XMPP server implementation is no better or worse performance-wise than any other type of network server. Its constructed using the same principles, and suffers the same issues.

I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.

The bulk of the discussion we had about framing Thes links constitute the bulk of the discussion we had about framing a couple of years ago:

http://mail.jabber.org/pipermail/standards-jig/200 2-January/000201.html
http://mail.jabber.org/pipermail/standards-jig/200 2-February/000215.html

A good summary of the discussion is here:

Basically, the simple framing we were considering (for backwards-compatibility reasons) might have made implementations easier under certain circumstances but also introduced issues (misframing).

How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?

As it stands, its quite straightforward to design a high-performance Jabber server that can handle many connections. Several folks (including myself) have done it.

Most implementations use an off-the-shelf callback-based XML parser (eg Expat or a SAX-based parser). When you get a read event on a connection, you read as much is there, and feed it into the parser. The parser fires callbacks, and you process the data contained in the XML. This all runs out of a normal descriptor readiness loop (select(), poll(), that sort of thing).

CPU time is kept as minimal is possible. We are parsing XML, so its always going to take a little more effort than a binary protocol (though modern parsers are pretty efficient, and there's ways to improve it if we're willing to write a custom parser that binds tightly to the network layer - zero-copy tricks, etc).

On the memory side, Expat in particular is pretty efficient - once its finished with an element, it gets cleaned up. So while its idling, the only state its holding is the top element and its namespaces.

Obviously, there's all the other session state thats being held for the connection (and the user attached to it), but this is unrelated to framing.

So a XMPP server implementation is no better or worse performance-wise than any other type of network server. Its constructed using the same principles, and suffers the same issues.

The certificate side of things is exactly what hurts, as a user. Either you pay bucks, or you use CAcert. But either way, the steps are far, far more complicated than "gpg --gen-key".

Also, to illustrate what hurts as a developer, compare the current OpenPGP protocol to the new End to End spec.

A good summary of the new E2E spec would be "wrap the XML which made things so simple into another format which will require you to write a new parser, then encrypt that, wrap it in S/MIME, and put it back into the XML."

Sorry, five years, my mistake.

This may be true *now*, but sooner-or-later enough people in positions where their influence is important will realise that an open, IETF support, XML-based messaging client makes more sense for their business than tying themselves into a proprietry networks that will eventually be questioned by organisations like the FCC.

Failing that, check out the Jabber Components and MSN/AOL/ICQ/Yahoo!/SMS/E-Mail gateways, your clients need not worry about 'crappy lame official clients'

There are probably a few things to say.

The XMPP spec everyone has now read describes a method for mapping XMPP over TCP. It also says that TCP is only one example of a transport for the protocol. A further JEP, JEP-0124, describes binding XMPP to HTTP... thereby HTTP becomes the transport for XMPP.

Of course, they could then invent XMPP over UDP, with one stanza (or frame) per UDP packet. Since UDP already tells you how big the frame is, your requirements are satisfied. But in all honesty, you'd have to layer the reliability stuff on top of UDP to make it usable in any real applications. :-)

Also, even in the case of the TCP binding, you don't really have to write a parser if you start with an existing parser which doesn't provide full functionality. XPP2 is an example of this kind of parser, where you can incrementally chew through and ignore tokens until you hit something you care about. All you would keep a counter for "depth", and accumulate the raw text until you hit depth 1. During the processing, you could take note of anything you care about (e.g. if you are a server, you primarily care about the attributes on the stanza itself, which say who the message has to go to.)

Since I've done this before, it can't be too hard. Harder than should be necessary, perhaps, but it isn't rocket science, either. And no, I didn't need to write my own parser, so I didn't have to worry about violating the XML spec in any way. :-)

Since XMPP has been in development for a while, hopefully it shouldn't take too much time for it to climb the Standards Track to full Internet Standard. Right now, XMPP is in the Proposed Standard category, which is the first step (look at the bottom of the list).

The next level up is Draft Standard. To become a Draft Standard, the RFC has to be a Proposed Standard for at least six months, have two independently developed interoperable implementations, and have had "sufficient" successful use. I think that Jabber is pretty much a shoe-in for this category. Several servers been in operation for years from which a large amount of experience with the protocol has been gained, so there shouldn't be any contention about XMPP not being mature. There are many independent implementations, so that shouldn't be an issue either. I don't think there will be any problems getting to Draft Standard in six months.

The final step in the Standards Process is Internet Standard, where the RFC retains its RFC number, and gets the all important STD series number. A standard needs to be in the Draft Standard category at least four months (or until at least one IETF meeting has occurred, whichever comes later). On the technical side, there needs to be a significant implementation of the protocol and much more experience using it needs to be gained. The level of maturity for Standards is such that the protocol is believed to be beneficial to the community. Again, since XMPP has been in the works for over two years now and there are now commercial implementations, I don't think there is a problem with the usage requirements. Furthermore, as the only open messaging protocol, it has a large value to the Internet. Thus, I think getting Jabber to full standard easily is not out of the question.

In about a year, we'll have an Internet Standard for IM and prescence (and an open one, at that)!

Jabber is that little jem in the back of everyone's minds, it's great, yet nobody notices it. Very much the Linux of instant messaging.

It's open, easy to understand (if you were so inclined you could type the raw XML yourself) simple yet scalable, and improved by JEPs (Jabber Enhancement Proposals) so even though there may be new features (such as vcards, buddy icons, user tunes), the underlying protocol remains the same.

I love Jabber, it's the greatest IM protocol out there. All it needs is users.

And with links:
http://www.jabber.org/oscon/2004/jabber-bootcamp.p pt
http://en.wikipedia.org/wiki/Jabber

Yeah, its work is still in progress. And in addition to XMPP proto there are JEPS (Jabber Enhancement Proposals), which update more frequently than core.

I glanced at ejabberd recently and was initially spooked by the choice of the language - Erlang. Thought it was some obscure toaster programming language. Turns out its from Erricsson, opensourced, and designed for fault tolerance and things like routers and servers.

Can someone point to a good review of the most common, free Jabber servers? (Possibly for Windows: Jabberd 1.4.x; Erlang; some Java ones, now including the Jive)

The Jabber.org's server features page is a good start, but says nothing of reliability and general feel.

I glanced at ejabberd recently and was initially spooked by the choice of the language - Erlang. Thought it was some obscure toaster programming language. Turns out its from Erricsson, opensourced, and designed for fault tolerance and things like routers and servers.

Can someone point to a good review of the most common, free Jabber servers? (Possibly for Windows: Jabberd 1.4.x; Erlang; some Java ones, now including the Jive)

The Jabber.org's server features page is a good start, but says nothing of reliability and general feel.

Probably not, as there's no Jabber Enhancement Proposal for it.

I wouldn't doubt video/audio chat in the near future though.

.. and let me add that Jabber is, like most (not all) things OSS, nothing but a ... copy of a commercial service.

Where's video or audio IM

buddy icons

I've tried some of the Jabber client (e.g. GAIM) and they are awful ... in terms of both ease of use and functionality.

.. and let me add that Jabber is, like most (not all) things OSS, nothing but a ... copy of a commercial service.

Where's video or audio IM

buddy icons

I've tried some of the Jabber client (e.g. GAIM) and they are awful ... in terms of both ease of use and functionality.

I agree that clients don't do Jabber file transfer nicely but I disagree on what you said about the standard. Its fine. Look at JEP-0095: Stream Initiation. Here, the entities negotiate the best way to transfer a file. If they are on the same LAN... then just open up a port and listen like ftp. As a last resort do in in-band.

I use AIM, Yahoo Messenger, and Jabber (all via Trillian) and Jabber is by far the most featureless of the three. Where's video or audio IM, buddy icons, etc. ?

What's being touted here is that Jabber can function as groupware for intranet messaging, and that it is a viable option for IM in the enterprise. But even for Internet messaging, it has a very attractive feature: encryption.

Trillian Pro offers 128-bit Blowfish encryption for ICQ, but that requires both parties to use Trillian Pro (a non-free Windows client).

On the other hand, Jabber is more readily extensible, and already offers both SSL and the somewhat SSH-like JEP-0116 encryption scheme.

I know some international business people that have already adopted Jabber for its privacy features. Jabber may never take hold among teens and "tweens", but it has a chance among other groups, such as Internet professionals who (believe it or not) conduct business via instant messaging.

While an open IM application can be useful in a defined group or organization for messaging, obviously, a standalone IM application is of limited utility on its own if you're already communicating with people on other IM networks.

This is why Jabber supports "transports", server components that allow seamless connectivity with AIM, ICQ, Yahoo, MSN, SMS services, and even IRC..

For those unaware, iChat has always used the Jabber protocols for its local (Rendezvous-initiated) messaging. This just dusts off and reveals full-fledged support for Jabber.

Why Jabber? Because Jabber is a completely open IM standard. The IETF has accepted the core Jabber protocols and has standardized them as XMPP, an open IM protocol.

For those unaware, iChat has always used the Jabber protocols for its local (Rendezvous-initiated) messaging. This just dusts off and reveals full-fledged support for Jabber.

Why Jabber? Because Jabber is a completely open IM standard. The IETF has accepted the core Jabber protocols and has standardized them as XMPP, an open IM protocol.

This is why I like Jabber. Open like email, works like email, but with the added bonus of presence information and required authorization to add somebody to your list. (People can send you messages if they're not added, but you can easily block them.)

Hooray for Jabber!

Jabber CAN talk to AIM.

And you can use other servers as gateways (or transports), even if your own doesn't support it. Look here: http://www.jabber.org/user/userguide/ar01s12.html.

Another incompatible instant messaging system? Ick. I'd much prefer people just started using Jabber instead.

Why not Jabber at:

http://www.jabber.org/

Jabber

jabber (http://jabber.org/), does work with servers, but it's not with one big central server, but more like with email: a lot of independant servers. Jabber also allows encrypting your messages with pgp or http://gnupg.org/.

That is mind bogglingly inefficient. Its like POP clients checking for new email every X minutes. Polling is wrong wrong wrong! Check out the select() libc call. Does the linux kernel go into a busy wait loop listening for every ethernet packet? no! it gets interrupted when a packet it ready!

http://www.mod-pubsub.org/
The apache module mod_pubsub might be a solution.

From the mod_pubsub FAQ:
What is mod_pubsub?

mod_pubsub is a set of libraries, tools, and scripts that enable publish and subscribe messaging over HTTP. mod_pubsub extends Apache by running within its mod_perl Web Server module.

What's the benefit of developing with mod_pubsub?

Real-time data delivery to and from Web Browsers without refreshing; without installing client-side software; and without Applets, ActiveX, or Plug-ins. This is useful for live portals and dashboards, and Web Browser notifications.

Jabber also saw a publish/subscribe mechanism as an important feature.

To use the over-hyped XML paradigm, standard tags would allow every IM vendor to talk with each other. Then more would use IM, allowing the vendors to add features and lower pricing (economy of scale).

The Jabber protocol is based around XML, and is in the process of being standardised by the IETF in the XMPP working group. It's also decentralised, so ISPs can offer their own servers and still have people communicate cross-network.

Unfortunately, that means that the existing heavyweights (AOL, Microsoft, etc) lose a hell of a lot of control, so they are unlikely to support it. I'd expect them to compete with each other until it becomes clear that one is going to win, and then the others will throw their weight behind XMPP.

Right on - Jabber and Jabber4R (or JabberPy). Word.

If it uses middleware to translate between them, then it most certainly does sound like Jabber. GAIM, no, Jabber yes.

However even though this uses MS middleware, it could still be a good thing as it might make MSN/Yahoo/AIM less likely to break their protocols just to stymie the open source clients. Maybe not, maybe they will just tell MS to update their middleware, but no way to tell just yet.

Jabber has offline messaging.

The problem with offline messages and ICQ/MSN is that they must be stored on a central server. This might potentially take up a lot of space. Jabber on the hand doesn't use a central server, but is decentralized just as email.

Waste

Kdx

Jabber

Well, I'm all for yahoo blocking 3rd party IMs because hopefully people will stop using their service and I won't have to build gaim from cvs once a week (okay, not every week) so I can IM people who won't give it up.
The sooner people start moving towards open protocols like jabber, the easier it is for all of us!

My $.02

First off, Jabber.org's list of public servers and their capabilities is a PITA to read. (Why do you have to go to the website in the first place? Shouldn't the list be maintained in such a way that you can access it from Jabber clients?)

There is.

Of course, even though it exists, that doesn't mean that people like you will even notice. :-)

Anyway as to the issue of servers being unreliable, you could always take somewhere like this as a hint of which servers are more stable than others.

But in keeping the list inline with the users' experiences, you need the users to actually complain! One of the only problems we have on our server (jabber.zim.net.au) is that when a user has an issue, they don't even ask customer support. If customer support aren't told that a user has a problem, then how do they know there is even a problem? We didn't find out about Yahoo being down until about 20 hours after Yahoo fucked over all their users.

Haven't you heard of XMPP?

Now look at the IM universe. AIM, MSNM, Y!M, ICQ, Jabber, etc. Of all those systems, only two work together...

Woah there boy. Methinks your inclusion of Jabber in that list was a little hasty. Jabber has many components for connecting to other IM networks. I noticed that the Yahoo component has stopped working for me today. Oh well, no loss. I don't know anyone on the Yahoo network. I just added it for the hell of it because I already had a Yahoo email account. Bye bye, Yahoo!

Now look at the IM universe. AIM, MSNM, Y!M, ICQ, Jabber, etc. Of all those systems, only two work together...

Woah there boy. Methinks your inclusion of Jabber in that list was a little hasty. Jabber has many components for connecting to other IM networks. I noticed that the Yahoo component has stopped working for me today. Oh well, no loss. I don't know anyone on the Yahoo network. I just added it for the hell of it because I already had a Yahoo email account. Bye bye, Yahoo!

Jabber is the only free, open IM standard that's in relatively wide use and there're lots of clients available for it - I personally use Psi. I've switched long ago and haven't looked back.

I often chat with friends that still uses MSN and ICQ through Jabber's transports or whatever it is they call them :) Of course, the Yahoo transport is most likely broken too, but I don't know anyone that uses Yahoo IM, so I don't care.

For starters:

Jabber.

ietf xmpp WG.

ietf impp wg.

ietf simple wg (SIP + IM).

Wikipedia on IM.

PS: /. thought writing IETF is yelling, so I had to write ietf.

I've been a Trillian user since its inception. I donated via paypal to cerulean back in the day when you got a personal reply from their founders, and back before it was obligatory (to get the pro version). I use it for the same reason I use Linix, Open Office, and GIMP - because I'm not locked into a company's adware and (incorrectly or not) feel like I get more choice in how I use these apps. Of course, if everyone gave the finger to all closed IM protocols and used Jabber, we'd never have these problems.

You should really enlighten yourself. Jabber is a unique, distributed, open IM network with an elegant, extensible and easy-to-understand protocol. You can run your own server and have it talk to the rest of the Jabber network almost like email works. Jabber is really lightyears ahead of any of the "popular" networks today (which is not really "networks", but one or a few servers). Jabber is my only IM network, and I use it to keep in touch with my geekier friends. All the non-geek friends are still on MSN, where they are obliviously happy, but why would I want to IM with them? ;)

Let's face it, IM is not rocket science. The basic functionality is easy to code, and, unsurprisingly, there are already tons of open source clients out there. The cost per user to operate a server is minimal, too, which means: Anyone who's trying to charge you money (or for all that matters force you to receive advertisements) for basic IM services, is attempting to rip you off. If you want to make use of functionality in AIM or MSN Messenger or Yahoo! Messenger which open source clients cannot offer, then you'll be using their official clients anyway. If not, you have two options: Cave in to their extortion, or switch to an open protocol like Jabber.

Btw, that's one reason why many companies want TCPA. It would give them an unhackable way of enforcing a particular client.

Yahoo has some nice features, but I'm also left wondering when the shoe will drop and I'll end up with spyware or giant ads with it. I haven't looked at Jabber in quite a while, and I know that it tries to be compatible with other IM services. But only for chat... I actually use my webcam with Yahoo. Yeah, I know there are alternatives, but it's just convenient to have it in one package.

I really shouldn't hit "Submit" without first having morning coffee.

Protocol: Jabber. Best client for it? hard to say, but my favorite is Psi. And I'm working on spreading the word to everybody that I can.