Jabber

I sent this as an email to Dave Winer but I'm posting it here so he has somewhere to point:

This is just a shell of an idea hardly worth blogging, but if you're getting into the comment spam issue it is worth sharing. tcp.im could be used to IM a managing editor of a Manila site when something is posted so they can take swift action. For a relatively low-flow site, one could even require all comments to be approved, and not unduly hamper flow.... at least while a managing editor is online.

There are obvious issues but its an idea worth tossing around, I think.

Untitled markpasc post:

Hint for Radio IM: deHTMLize an item with string.htmlToEmail.

A few hints and tips regarding coding and decoding in tcp.im:

Both AIM and Jabber have the ability to send HTML messages on the network, as do many of the other IM systems. (All that I know of can send formatted text, I don't know that they are all HTML as opposed to, say, RTF.) However, they are almost completely different. AIM sends half-assed, crappy HTML without close tags, inconsistent capatalization, etc. Jabber strictly requires compliant XHTML, or you'll ruin the whole connection.

With the (impending) release of tcp.im to the general public, this marks a transition of my Jabber only feed.

If you are reading this feed solely to watch the status of the Jabber work as it goes public, you can unsubscribe now; it's done.

I will continue to blog interesting things people do with Jabber in Radio and any further Jabber-specific work I do, if any.

Heads-up, some time in the next few hours (Murphy-willing) we're going to release tcp.im, which allows Radio and Frontier to be an instant messaging client or server (either can be either). It was a collaboration between Eric Soroos, Jeremy Bowers and myself; with Jake Savin doing the close. There may be some bugs and more docs to write over the next few days. Should be final on Monday.

Excellent.

tcp.im essentially exposes a reasonable amount of the intersection of the capabilities of AIM and Jabber, with an eye towards easily incorporating anything else that wants to play. So in technical terms, the framework is not necessarily terribly capable. But because of the cross-IM-platform nature of the code, it's gonna have a lot of juice.

A Jabber update: As you may have seen on Scripting News, there's this "tcp.im" thing which we're still hammering out. Exactly what happens with the Jabber code I've written depends on what happens over the next few days, and whether or not Dave decides to ship it standard to everybody with Radio. (Personally, I'm hoping we can get both Jabber and AIM support over the next few days to the point where we can ship both, but obviously what finally happens isn't my call ;-) )

A new release of the Jabber framework for RU and Frontier. (The prefs page will probably work only in RU.) Info in the title link, and the changes page (if you've installed it).

I've done the coding for the transition to the new framework architecture for Jabber, and I'm now testing it, trying to run down all the code paths, checking my TODO list, seeing what happens when I disconnect the network. Also got a bit of documentation to sift through and correct, which I'm doing right now.

I also want to once again look into the possibility of adding Jabber functionality to xml.rpc, since I don't need a connection reference any more. (I forgot to list this as another good reason to transition to this architecture.)

I've definately decided to go with the Jabber stuff I described earlier. A few more advantages:

Threading issues are simpler. If the users are responsible for re-establishing connections, there's a nasty time while the system is logging in, but the server will reject any other messages, like I said. If I take control of the re-establishment, it's easy to block these messages. There are also a few misc. places where I could construct a multi-threaded scenario where something bad happened; this reduces, and I think eliminates, those. (I need to double-check the elimination claim, but even if it's false, the consequences of being incorrect are not that critical.)

The Jabber framework approaches a critical turning point in its evolution: How the API for connecting other Radio/Frontier stuff works. Actually, we've stepped a bit past it, with the release of .7, which has a first cut at such an API. And I've learned a few things.

Right now, the whole API centers around the idea that you may possibly have multiple Jabber connections. Every call takes a "connection reference". That's not really a big deal. The problem comes when the connection is terminated, which has been happening on my at least once a day. (Not just my Radio client, either, but the various IM clients I'm using for testing, too, so it's not my code.) The problem with the current API is that when you register to receive events, you register on a per-connection basis. If the connection drops, boom, no more event notification.

In case this is your primary way of getting info about the Jabber stuff I'm doing, I've released a .7 release of the Jabber verbs, which can be obtained by downloading or updating your current copy. Big news is the introduction of an event system, which makes responding to things easy, now. You can write a bot.