Jabber Update

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.)