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.
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.
The only solution I could find was to make tcp.im.send only send text; if you try to send HTML, it will actually encode it such that the receiver will see the HTML. Thus, tcp.im can't actually send HTML over the wire. However, the highly beneficial side-effect of this is that it is perfectly possible to reliably send HTML messages, as long as the user manually types the HTML, and that HTML need not be compliant with anything (even in Jabber), because the IM network just sees < (encoded entities). The blog poster and the manila poster both use this to their advantage. Work with this, not against this; do not try to use the IM system's HTML capabilities from within tcp.im.
You can use the drivers directly if you need to for some application.
The corresponding philosophy on the receiving end is to try to receive exactly what the user typed (except that whitespace may be altered by the transport, as AIM does), without any formatting.
This information will be particularly importent to anybody wanting to write a driver for a new IM network, but it will matter to tcp.im developers, so they know what they are getting and what they are not.
So, as markpasc suggest, string.htmlToEmail is a good way to convert any HTML you might want to send into pure text, which you can ship around however you like.
This post may later be altered to just point at the appropriate documentation.
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.
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.
I did some research on the web a while ago; as far as I know, tcp.im is (currently) unique. There is no library available that tries to flatten the differences amongst the various IM networks, to make it easy to write tools that works with all of them. (I may be wrong, of course.)
Underneath tcp.im, there are capable drivers for both AIM and Jabber. Att DJ Adams and Jabber crew, with this release, everybody will have Jabber drivers in their Radio Userland installs. You can look at the Jabber driver documentation now, if you like.
There's a lot of fun to be had, both with the tcp.im framework, and working directly with AIM and Jabber. Let's rock!
As a final note, this officially terminates any usefulness TextResponder may have had. You're not likely to care, but in some abstract way, it should be mentioned here as a form of closure.
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 ;-) )
If it isn't shipped standard, it will still be an easy-to-install Tool released by me.
No matter how it ends up getting distributed, here's where the code stands now: Other then bug fixes and some cleanup, I'm declaring it complete. It support sending and receiving messages, sending and receiving presence info, sending and receiving subscription requests (automatically accepting all subscription requests), and extension with arbitrary iq namespaces, which is powerful enough to implement most things currently being actually done with Jabber (as opposed to spec'ed-without-implementation), such as Jabber-RPC (now actually some sample code, rather then an integral part of the core; this is a good thing) and the pubsub stuff.
Mental note to self: Remember to confirm and write up opinion on why multiple query tags in one iq tag is a mistake, and send to the Jabber protocol list. (Basic premise, which I need to check: iq tags have an id, which should be one-to-one: One id used once outgoing, and the incoming tag with the same id should correspond to that outgoing tag, in the form of request-reply. IIRC, as spec'ed, iq tags may contain an arbitrary number of query children, doing arbitrary things. The problem comes in that error messages get associated with the iq tag, again IIRC, which is why I need to confirm it. So, you can send an iq tag with three parts. Suppose the second errors. Do you send an error back? What if two of them error? Can you tell which errored? (No, I don't think so.) Should you re-send the third part? If I'm representing this correctly, this is a mis-match in the protocol, and while it's technically too late to correct the actual protocol, people should be encouraged to write clients that always send 1-to-1 iq/query messages, and feel free to reject later query elements.)
|Past Posts ->|