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.

Couldn't pass up passing this along:

Looks like the Internet has reached self-consciousness.

And hey! This is my first blog in a while. Weeeeee!!!

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.

This is what eXtreme Programming looks like when it goes wrong with way too many index cards or in this case Post-It notes:

In only a few weeks Hoosiers will be able to vote on who should be their representative in Washington, and the Hoosiers of the fourth district still haven't witnessed a debate between Steve Buyer, our current representative, and Dr. David Sanders, the Democratic challenger. Dr. Sanders has invited Mr. Buyer to hold a debate between the two so that the voters of the fourth district can make an informed decision this election. But Steve Buyer has not accepted Dr. Sanders' invitation for an open and honest debate.

A voter has to ask why would Mr. Buyer not be willing to debate? There could be one reason why he has refused to debate Dr. Sanders: he's afraid to face the facts and take responsibility for what he's done as chair of the Veterans' Affairs Committee.

As I've helped Dr. Sanders' campaign, I keep learning more and more about how Mr. Buyer, as chair of the Veterans' Affairs Committee, has done more harm than good to the Veterans of our great nation. Mr. Buyer has done such harm that nearly every veteran, minus Mr. Buyer himself, hates the job he's doing.

I learned quite a bit about the horrible job Mr. Buyer is doing this past Monday, September 25th, when former Senator Max Cleland spoke in support of Dr. Sanders. From what Senator Cleland stated: Mr. Buyer has continually refused to allow veterans' organizations created by Congress to testify before Congress, has failed to equip the VA with proper funding for the veterans that are returning from Iraq and Afghanistan, and has continuously supported cuts to the benefits that we have promised our veterans.

Perhaps that's why Mr. Buyer has not accepted Dr. Sanders' invitation to a debate--he's afraid the truth will be known that he genuinely does not support our troops.

I followed the link TechCrunch posted to oDesk since I need some work. I found some job posting that I found interesting and proceeded to sign up. Low and behold the first service agreement I read just wasn't palatable. From my understanding of their Professional Services Agreement, any pre-existing intellectual property that is incorporated into a project can essentially be used for whatever purposes oDesk wants.

I wouldn't have an issue if this granted a license to the company that has requested the work, but it is oDesk—the site that connects professionals with those that need work done. I have a body of code that's gradually getting larger that allows me to be more productive, and I like to set my own terms on its use. Sorry, I won't grant an unlimited license to it to a company whose unstated business is to hoarde IP.

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.