In working with the IM Gateway Plugin, there has been a pressure to try to improve the way transports are handled in general. I’ve begun the process of seeing what could be done to improve things, but one of the big sticking points seems to be not having the transports in your actual roster.

Now many clients provide an option to simply hide transports from your roster. IMO, this is not a bad way to handle it. Leaves it up to the client to decide whether to hide things or not. It also allows for the end user to decide whether or not to see the transports or not. I, for example, like to be able to see the transports and how they reflect when I’m logged in, what my status is, etc. (because, for example, AIM only does available and away, none of the other statuses, and this is neat to see in my roster because I know that AIM folk don’t know that I’m set to do not disturb) It also allows clients like Psi and such to provide me a way to right click and choose log out. (equiv of sending a directed presence packet)

So how would you go about having a transport detect that you’ve logged in if it’s not in your roster to be telling you so? Well you can cheat for one. The IM Gateway Plugin allows me to use internal listeners. This solution, of course, isn’t going to help external transports a lick. But for the plugin, it’s nice. Another way might be to require some sort of ad-hoc command to log into legacy services. Like instead of auto-logging in, you have to select “log me in”. But then how does it detect status changes and such? More ad-hoc commands? Eww! How many freakin’ ad-hoc commands does it take to screw in a lightbulb. ;) Another way could be to create some sort of ‘trust’ relationship with a transport. So a transport could indicate to it’s attached server that it wants to be notified of any presence changes. Not so sure about that either. I think that was already addressed a long time ago in regards to transports wanting to interact directly with a user’s roster.

Long story short, I think this will be fine for the IM Gateway Plugin to ditch the roster, as it apparantly confuses some folk to see transports in their list, but I don’t think this is viable for other transport implementations.

That said, some issues have come up that -should- help other transports. I’d like to, for example, write up an XEP that focuses on how to handle user preferences. I’m not talking things like, “what theme for your client” but rather things that are handled on the server end. For example, mail notifications. AIM has them. Not everyone wants them. User should be able to go in and choose “no or yes” for mail notifications. =) These are enabled or disabled on the transport end and a client shouldn’t be expected to have to be bothered with ignoring lots of things it doesn’t want in the first place. This is basically an ad-hoc command type of thing, but I’d like to standardize it or make it a “best practices” type of thing. That way client devs could fairly easily go “oh this one supports user prefs, I’ll provide an easy link for that”. Something like that.

Another one is a XEP that I had intended to write a while ago… basically something similar to Jabberd2’s component protocol where the transport itself can connect and tell the server what jid’s it wants to be. This means that the transport could say “Hey, I’m aim.jabber, chatrooms.aim.jabber, and fries.aim.jabber” and the server could go “oh ok, well you got ’em” or “bugger off, those are taken”. Wildfire actually implemented this in a slightly different way than Jabberd2, but I think the same XEP could address both just fine. I believe I originally called this “Extended Component Protocol” or something like that. Who knows. It’s been a while.

On a side note, I think I figured out what was causing problems with Java-JML. Basically I kept getting a severed connection upon logging in. Turns out I think that the server Java-JML has for “fast login” is not a good one. Theoretically you are supposed to connect to a nexus first and it’ll tell you a login server. I’m doing that now.

BTW, Thanks to the Cenqua peeps for providing me with a Fisheye setup for Java-JML! I’m going to link that off the Java-JML site in a bit here. =) I love me some Fisheye.

« »