Jabber

Earlier today I setup an instance of HgWeb to host some old and new code bases of mine. Two of the repositories may interest those learning or looking to learn Erlang. Both repositories contain a simple project that doesn't amount to much of anything at the moment, though they could prove useful for some code reading/banging.

The two repositories are:

• Station: This is a super basic, simple HTTP server framework. It can currently parse an HTTP request which gets dispatched to a station behavior that you can define. The station behavior contains a function that gets called on each valid request and returns a response which is sent back to the requestor. Proper query string and form handling still needs to be done along with dispatching to different modules based on the requested path.
• mod_rest: This is an ejabberd module that adds an HTTP handler that allows HTTP clients to literally post arbitrary message stanzas to ejabberd. Those stanzas then get shoved through ejabberd's router just like any other stanza. My original use for this was to allow a Rails app to send messages through ejabberd without needing to be a full XMPP client.

You will need to install Mercurial to get the code onto your machine. It's the next best thing to git.

I just ran into a problem with iChat that would probably leave most mystified. I found out due to some unknown reason that iChat is very picky about the XML contained in its rosters. It doesn't ignore errors. Instead it just kicks you off saying that you have lost your connection.

The little snippet that was the culprit was a roster entry with a namespaced attribute:

<item jid='***@gmail.com' name='***' gr:t='B' subscription='both'/>

I'm not sure where that "gr:t" attribute came from, but that appears to have been iChat's choker. The only reason I noticed that was with Apple's Console utility. iChat was spitting out error messages to the system.log which included a block of XML that caused parse error 27, whatever that error means.

To get iChat working I had to use another client to remove and readd that roster entry. Not good for the neophytes.

I am left with a couple of questions though. Who uses the "gr:t" attribute, and what's it for? And can iCh

I slipped up a new site bitter.nolan.eakins.net the other day. It's my take on the don't make me think blog. I've already implemented a basic web interface and just slapped together an XMPP bot that makes Bitter much easier to use. There's a lot that I've left out, but I put a Bazaar repository up if anyone wants to play.

Lemonade was brought to my attention for the guy I'm doing work for. It's a set of IMAP extensions that make IMAP more suitable for mobile phones and devices. Some of their goals obviously overlap with the work the XMPP/Jabber community has been doing. The most obvious being the extensions to handle streaming multimedia content. Looking through their list of goals in their charter, practically every item seems to be handled one of our RFCs or XEPs already. Perhaps its time for the IETF's left hand to check up on its right hand.

Alex Russell posted his slides about which he used at EuOSCON. On slide 19 he has a table listing the TCP init times on a couple of cellular networks:

Alex focuses on HTTP since calling him a maestro at JavaScript is an understatement. Obviously this is an issue for the subject of his presentation: mobile AJAX. There is an obvious solution to sending little snippets of XML without the TCP overhead: a better protocol.

I could name at least one that could deliver for AJAX along with providing a feature set required for cell phones. I'll leave it to you to guess.

I've been secretly and passively working on an XMPP Lisp library. I was having trouble with SASL, but I got that going after properly configuring my server (the order of auth_methods in ejabberd matters!). Since I can actually login, I've been seeing if I can login to my various accounts. So far I haven't had much trouble until I tried to login to Google's Talk server.

For whatever reason, Google decided to invent their own SASL method: X-GOOGLE-TOKEN. This is also the only SASL method they support too!

It might be to brash to damn them just yet. I haven't tried to get TLS working, so the more common methods could still be lurking behind that wall. Consider this a warning to other client developers, you may need to support TLS to play on the Google server.

More updates to follow...

I doubt anyone other than myself and a few spammers follow the comments on my blog. I got a couple of decent replies to my Commoditize Messaging...Again? post. For those who have an interest in messaging, these are definitely worth reading.

Elsewhere in the messaging landscape: Alex Russell, the man who's been doing Ajax since the days it was called DHTML, has announced Bayeux multiple times.

Poking around InfoQ I discovered an announcement about the Advanced Message Queue Protocol. Its stated goal is to commoditize messaging—again. I have to smack my forehead. The groups behind it are JP Morgan Chase, RedHat, Twist, Iona, Cisco, and others. Apparently they missed the announcement about all of the libraries and servers that already exist for XMPP which cover more platforms than AMQP.

AMQP offers point-to-point, publish/subscribe, and many-to-many messaging. It's a binary protocol which could provide a slight increase in speed over XMPP, but it lacks a standard message body format, presence, and everything else the JSF has pushed out. Not to mention that AMPQ still hasn't reached version 1.0 yet.

We could learn a few things from them, like their requirements. With some advocacy in this space, and by replicating their reliability and queing requirements XMPP could dash John Davies' goal of making AMPQ the dominant messaging protocol by 2011.

Bob Wyman has spoken about the rumor originally posted on TechCrunch. He describes their issue as a problem with a minority of PubSub's shareholders which points to their problem: one man, one vote. So the moral of this story is to stick with the policy of one share, one vote.

TechCrunch is passing along a rumor about PubSub.com that hopefully isn't true. If it is, hopefully Bob would care to share his experiences, and if it isn't then the record needs to be set straight.