There is an open letter up on the Cocinella website about why IM clients which come bundled with support for multiple protocols are actually bad for interop.
I actually agree, but the problems listed about using transports as the solution are not merely theoretical.
I have been a Jabber user for more than six years and I have not found a single remotely hosted transport that I can rely on for the critical task of actually communicating with other people.
As far as I’m concerned, jabber.org should be hosting the most reliable transports on the planet and then making sure that other servers who want to run them can do so in a reliable way. There is nothing more likely to turn someone off than the promise of practical cross-protocol support turning out to be nothing more than wishful thinking.
I love this idea of Personal Unit Tests.
It’d be easy enough to fill in a piece of paper each day or remember to fill in the wiki page with my details, but I think I can do better than that (read: that’s too easy and dull, and would get me started sooner).
How my thoughts progressed:
- cron a script (maybe even a GUI with wxPython) to popup at the start of each day and ask about the previous day’s tests from a hard-coded list, taking pass/fail answers and saving them to a wiki similar to how I record my daily work
- cron a jabber bot to send me a data form with pass/fail radio buttons for hard-coded tests and save to a wiki page
- cron a jabber bot to send me a data form with pass/fail radio button for hard-coded tests and save to Google Spreadsheets
- cron a jabber bot to read questions from the first column of a Google Spreadsheet, present them to me using a data form, then save the results back to the spreadsheet
Doesn’t that all sound so much more like Web 3.0?
So let’s look at some practical issues. Data Forms is XEP-0004 – the last time I looked for supporting clients was 2005 and they were thin on the ground.
The important issue back then was that according to the spec
<jabber:x:data> stanzas can be sent as a child of either an
<iq> stanza or a
<message> stanza but only the former was supported in most tools and I needed the latter.
Looking again, apparently Smack now supports this (and so hopefully Spark, the client based on Smack, should do too – this page seems to confirm it) as does Gajim . Exodus has supported this since 0.9.0.35. As far as I remember Psi supported the type in 2005, so I can only hope that two years has been enough to also support data forms.
So it looks like there’s enough client support for this to be feasible. Next post I’ll see about getting some of this running in practice – in the meantime you can play with one of this year’s Summer of Code projects, the Data Form Designer Suite for XMPP.
At work we’re playing with Openfire, the Java-based Jabber/XMPP server. There are parts that are *cough* sub-optimal so we want to fix them. It’s open source and builds using Ant. So far, so straightforward.
I want to modify some core code so went looking for the unit tests to make sure that my changes wouldn’t break anything. Oh dear lord. A few hours of sobbing to myself later and I can only hope that they get someone for this job really soon.
The latest Atom-over-XMPP IETF draft expired two months ago.