More Jabber design by musing

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.

I (barely) started on trying to automatically create a new connection and slide that into place, but that was rapidly becoming a kludge, which I thought was bad because up to this point, the code has been kludge-free. If it's going to be a built-in, it probably ought to stay that way. (The system has to block outgoing messages, so you don't send an outgoing message during the re-establishment, except the messages it needs to send to logon... it just wasn't pretty.)

I've learned a lot about Jabber in the last couple of weeks, as you might expect, and I'm starting to think it's time to challenge the initial design decision. When I first started writing the system, I had thought that if you wanted to provide two seperate services, you would create two Jabber connections, and thus differentiate input based on which connection it came in on. So, I might link TextResponder on one connection, and a presence monitor on another. This is incorrect; not only does Jabber provide (useful) ways of seperating input coming in based on source, it provides an embarrassing profusion of them: messages by thread, the whole id system, what group chat room a message is coming from, namespaces in the iq tags, and in server version 1.4.2 and beyond, a sub-resource system complete with query system.

I think based on my experiences, the API I've developed is a dead end. Right now, if a disconnect occurs, even if I hack something together that notifies the clients, and requires them to try to re-start the service if that's what they want, it gets messy as umpteen clients all try to re-establish the connection at once.

To alleviate the difficulties of the architecture, I think I will be going to a one-connection model for the Jabber framework. Your interface to Jabber will be the registration and unregistration system. As long as there is one service registered, the system will do its darndest to keep a connection alive to your chosen Jabber server. You can ask to be notified if there's a failure, and the system will retry periodically, subject to the user's prefs.

Once the connection is re-established, it will be the framework's responsibility to re-establish all the services that it was providing before.

Hmmmm... the more I think about this, the more I like it. Connection management is taken out of the (internal Radio/Frontier) client's hands, which means they don't need to worry about it, except inasmuch as they care. That means that jabber.openConnection, abortConnection, and closeConnection disappear from the public interface. That's actually pretty cool. This is much easier for the client.

In fact, it's kind of easier to program, too, now that I know where I'm headed. There will be a transition time, but it shouldn't be all that long; most of the handler code still works just fine.

Wow. Unless there's a problem I haven't forseen... and I'm pretty sure at this point I've absorbed the problem well enough to know if that would happen... this drops the complexity of Jabber programming in Radio another notch, by allowing the Jabber-in-Radio programmer to worry about connection states only if they want to. I didn't think there were any more notches. I gotta sleep on this, but as I think about it, I slowly grow to like it more; usually a sign that it's the right answer.