Category: Transports

Busy busy busy… too busy?

The problem with personal projects is just that, when the person in question gets interested in another project or busy or whatever, development stops. This is what the current status of PyAIMt and PyICQt is. I am having a lot of fun with the IM Gateway plugin for Wildfire, and as a result I don’t feel interested in putting any time into PyAIMt and PyICQt. Are these two dead now? No. I still have “things I’d like to do with them” in my head. It’s just most likely we’ll see a 1.0 version of the plugin before I touch PyAIMt and PyICQt again.

One thing that the IM Gateway plugin has brought me is that I’m now quite comfortable working with other folk on the same source code. That said, I’m trying to weigh the pros and cons of enlisting help with PyAIMt and PyICQt. There are quite a few folk that are interested in using it, a few folk who submit me patches from time to time, and certainly general interest in the transports. So my question posed is… Are there folk out there who are fairly experienced python programmers who would be interested in becoming active developers of PyAIMt and PyICQt? I am not handing off the project and will continue to be the project lead, and will continue to put development time into them as time permits. Anyway, I have not yet decided on this, I’d just like to hear from folk who might be interested in contributing. If I see some interest that’ll help drive my decision. =D

On a semi-related note, I continue to find java with an IDE to be fun and interesting. I think working with java without an IDE would be maddening due to how long it takes to compile and test things in the environment I’m using it in, and it’s certainly saved me a ridiculous amount of time in debugging stupid typos and crap. The IM Gateway plugin itself is going pretty well but unfortunately there’s a lot of work that involves working on support libraries as well. The original developer of Java-JML turned over development to me so I’ve been working on that. That’s pretty fun, I know more about the MSN protocol now than I ever expected I’d know. The Yahoo library is … kind of a pain actually. =/ Right now Yahoo is the biggest source of issues for me. Joscar for AIM/ICQ is a damn fine library, but I want to move to using a more simple API and I can’t seem to figure out how I use Joscar’s simpler API. ;) Perhaps I should like… ask them instead of just blogging about it. I tried figuring it out from Adium X but yeah… =) That’s kind of a weird setup. I need to work on implementing the old school ICQ authentication because, unfortunately, the “new style” AIM auth only works with newer accounts. (how bizarre) I’ve still got a lot to work on with IRC as right now it’s a mightily talkative transport and I doubt most folk want to see all of that. =) My biggest issue at the moment is that I’m fighting with AJAX support in the web interface. Trying to use DWR… seems like it should work fine… doesn’t. I wanted to figure this out on my own but it looks like I shall be deferring to the Jive folk to get it taken care of. So many things to do.

So anyway. Thinking back, I remember that the thing I thought was so awesome about XMPP is that the entire spec was written out and ‘open’. My first endeavour was that I like the Zephyr system from MIT and thought, based off the open protocol, that it would be neat to implement zwgc and friends except to communicate to Jabber/XMPP. This formed into JWGC. Transports came later, etc etc. The great thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. The bad thing is that the openness of the protocol leads to a great feeling of being able to write your own client/server/whatever to learn how it all works and go from there. =) Now, I don’t think this truly is a bad thing, but it does lead to a -lot- of starter projects written and then ditched. I often see folk come jadmin and jdev asking about where to start in writing their own client/server/whatever, and typically they get a response of “why not just contribute to an existing project?”. If the person’s goal is to just learn, starting from the ground up is not a bad way to go. If the person’s goal is to get a server/client up and running that has X feature that all of the servers don’t have, contributing is definitely the better way to go. What’s the fine line between writing your own and not writing your own? I certainly can’t answer that. Note that I think asking “why not just contribute…” is a good way to go about it because that encourages the person to say “well I just want to learn”, at which point ok, go for it. Or it encourages us to help point the person in the right direction.

Future Improvements?

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.

Wildfire plugin updates, and the Py’s

The Wildfire gateway plugin is coming along. Not as fast as I’d like at the moment, but I keep running into minor stumbling blocks outside the context of the actual plugin (read: getting sick, that sort of thing). That said, I’m switching internal libraries for MSN. The one I was using does not behave well in a multi-user environment. Furthermore, it had some kind of annoying debugging that there wasn’t an easy way to turn off. I’ve switched to a more recent looking library. It was between that and another one whose documentation was all in… I believe Korean. All things considered, the function call names were in english, so I could have muddled through, but if both look good, why not choose the one I can read. We’ll see how that goes. This one requires a little more knowledge of the underlying concepts of MSN’s IM. It’ll be fine. =)

As for the Py’s, I’ve done nothing with them for a bit now. The pubsub stuff I was working on was causing some file system problems and, on top of that, the recent updates to pep makes my work semi-useless. No worries, I’m glad to see it doable in a much nicer fashion. James is working hard on some wonderful new revampings to the underlying code for PyMSNt that I’m looking forward to pulling on over to PyICQt and PyAIMt. I will, however, watch and wait until things look like they’re good to go. I don’t have a gauge for this, so I’ll just post it aloud here… do people want me to put out a PyICQ-t and PyAIM-t with all of my current updates that’s an actual release? (underlying code will be cleaned up to lose the pubsub stuff first if I do that) Otherwise, I’ll be waiting for some bigger updates.

It’s interesting to note that looking at code in one language sometimes helps you clarify concepts in your head in another. Just the way joscar does a few things made me go “oohhhh yeah I could do that with pyaim as well”. *shrug* I thought it was neat…