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.)
It's looking good; failure is still a bad thing, as some messages may get dropped on the floor, but I don't think I need to nursemaid the connection any more. Perhaps most importently, it feels significantly more reliable. So like I said, this should be the beginnings of production quality code. (This is a benefit to me being on the @Home network; I had to handle bad network connections early, I couldn't just brush the problem under the carpet.) I wish my IM client would restore connections so transparently for me!
The only bad news is that the conferencing protocols look to be a disasterous mess right now. A couple of the sample uses of the framework I was hoping to implement are looking mighty iffy. I had hoped to push your news to a group; it looks like you might only get it to a particular account. I was also hoping to implement something for Weblogs.com to easily push the updates out on Jabber, but without a highly configurable conference group (I'd want to make sure only the Weblogs.com thing could post, or it'll get deluged in spam), that won't happen. I can't even find a spec I can code to, let alone a sample implementation to test against. The right answer might even involve programming a module for the Jabber server. (I could do it, but that's a bit more then I'm willing to undertake.) I don't even know that the servers even have the capabilities I'd need right now.
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.
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.
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.
|<- Future Posts||Past Posts ->|