More Jabber news

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

Production quality. The .7 release is suitable for playing, but because disconnections are such violent events, it's not suitable for production use. .8 will be the beginning of production quality, at least in theory. ;-)

As for anyone who may be playing with the framework and wonders if their code will be useless later, the answer is no. In fact, you'll find you'll need to make very few changes .7->.8; it will mostly be removing calls to "openConnection", and the connectionReference parameters. Feel free to play, and let me know what you find.

The last issue I thought about is the callback approach versus a registerHandler function, as I currently use. Radio uses a callback system throughout, where you drop your script/address-to-script into some table, and everything works. I can't *quite* do that for Jabber, as scripts need to give a little more information about what they want to do. For instance, for an iq tag catcher, I need to know what namespace you're interested in, which I'll store in a table by that name. However, if you know in advance where your script will go, if you put it there manually, everything will work, so in the final analysis, the registerHandler function is just a convenience.

I think I can get .8 out this week. Coding is fairly easy, but there's a lot of testing ground to cover; every capability of the system must be re-tested.