PyICQ-t
PyICQ-t 0.7 Released!
Well, after long last I released 0.7. I was very hesitant to do so as there are still a slew of bug reports open. Thing is, it’s hard to tell if they are still occuring. I wanted to get everyone on the same page. More importantly, I wanted more folk to be able to enjoy the new features. Here’s hoping it does not take too heavy of a beatdown of new bug reports. =) Typically right after a release is when I see a slew of new big bug reports, so I’m ready for them. Don’t be surprised if there’s a 0.7a out soonish, but I believe all of the major issues are worked out and I’m comfortable that I did the right thing by releasing it. I don’t know, I’m always nervous putting out a new release.
Impending PyICQ Release
Well, I just got the other style buddy icons working. Wouldn’t want them to bother using the same style of checksum, would we? 
Anyway, I do have a fair number of open bugs but I need to get PyICQ on a “everyone on the same page” release. Besides, people have been waiting on a new version for a while now. On the todo list are:
- Add support for JIT spool format (legacyjit driver)
- Update web interface admin pieces to be locked down to only admins
- Various doc updates here and there
Other than that, we’re almost there. Woot!
A PyICQ interview with myself
Why is PyICQ’s release taking so long?
Well, primarily because avatars and ICQ aren’t as functional. As I mentioned earlier, there’s other entirely different methods of handling icons and I am reluctant to release a new version until I have avatars happy. There’s plenty of bugs to tackle. =(
Well ok, then why are you working on the web interface?
Because I’m frustrated with the avatars are the moment and want to do something fun for a bit. =) I’ll get back to avatars soon. The web interface isn’t taking that long. My goal is to integrate WebReg into a built-in interface that comes with the transport. This will also provide a way for people without a full-service jabber client to register with the transport.
How are the encoding problems coming?
Sadly, it’s hard to tell. Since I don’t speak or write in other languages, it’s typically difficult for me to tell if it’s working correctly until someone else tells me it’s busted. It seems like every time I get the UTF support going good, I’ve broken something else in the process.
You were considering adding groupchat back… any luck?
No. I thought maybe I could connect to AIM chatrooms or something. Does not appear to work. I tried multi-chat functionality in the real ICQ 5 client and well, it’s not “real” chat support. It’s “we’re going to take you to this flash program that’s basically IRC”. Whatever works . . . but I think I’ll be yanking that support back out.
Any other big gotchas?
ICQ used to only be plain text messages. Period. However as of I think ICQ 5 they now have html-ified messages. This makes parsing the messages very confusing -except- that I did discover that there’s a flag that’s attached to the message to say “hey, this is html”.
Any other big noteworthy items?
Robert Quattlebaum hooked me up with a wonderful patch set to fix up xhtml support and a lot of other fixes. I need to massage it into both the PyAIM and PyICQ code.
Why massage?
Well, parts of his changes involve fixing the tlib pieces. Most of tlib is “stuff that was busted in Twisted 1 that we had to fix”. Twisted 2 fixed things and we started using the real pieces. So his patches to the tlib stuff I have to evaluate to make sure things are functional under Twisted 2. I don’t really want to have a “stub Twisted piece” again, so … well we’ll see. I always massage in patches anyway. There’s often minor tweaks I do here and there, or I move functionality around. I am trying to be very conscious of what should go in oscar.py and what should go in the transport, because oscar.py -is- still meant to go back into Twisted some day.
Any estimate on a release?
Not really, but I’m hoping for soon. I may put out a “lots of improvements but not everything is fixed” release at some point. Just to get more people on the same page, get us all working with the same thing, get those new features out. (there’s a lot of them)
Whatcha been doing with the web interface anyway?
Well, I used to have a “websecret” config option and there was one and only one password that could be used. What I’ve done is, with the help of thetofu’s code from palaver, switched the authentication to be “auth against a jabber server”. My goal here is that you can log in as yourself, if you are an admin you see admin stuff, but normally you just see some info about your account -or- you get to register from the web form and not have to deal with 8 bazillion “hey, wanna accept this buddy into your roster?”. Before I go too far into this I think I’ll enforce SSL. Anyway, I think this’ll be pretty fun. I also want to make it so an admin could change config options and shut down/start up the transport itself while leaving the web interface going. Don’t think that will be too hard.
Buddy icon fun
Well, as it turns out, I was missing an entire method of handling buddy icons in the AIM/ICQ world. There’s also an ability to attach a “hey, I have an icon, LOVE ME!” flag to your outgoing messages. Visa versa, you are supposed to pay attention to said flags from other people. Soooooo, soon there will be better icon support for PyAIM and PyICQ. I need to figure out how I want to handle this though. Not a long post for now, just wanted to mention that I’m thinking through this.
Ah the holidays…
Well, I’ve been so busy with holiday stuff lately that I haven’t had any time what-so-ever for PyICQ. That may or may not change when my holiday break actually begins. We shall see. I think I may need to implement some better checking of local copies of buddy icons as I think it’s possible to have a scenario where the icon is downloaded, isn’t convertable by PIL (maybe because you don’t have it installed) and yet I still record that I got your icon just fine so I never try to get it again. Some sort of “only update after I’m sure this worked” thing. Perhaps an ad-hoc command to clear the icon caches would be nice as well. Maybe admin only because that could result in some bothering of the particular install of PyICQ. I also need to work in a record of the SSI version I have.. . . welllllll maybe. That will require a lot of interesting work. Basically if I have a local copy of the SSI, I can say “hey, I have version X” and if that’s the latest version, OSCAR won’t send me a new copy. Much more efficient, but then I have to keep a record of key information about every buddy. That might not be a problem, but still. Lot to think about there. Definitely need some more ad-hoc commands for PyICQ. I was thinking about putting together a list of all of the JEPs and indicating whether I support that JEP or not. (and check for proper compliance) That might help me keep track of what I should consider implementing.
PyICQ coming along
Well, I can log into ICQ now. I can see ICQ user’s buddy icons, which was a confusing ordeal in ICQ5 to figure out how to set. What ever happened to ICQ being a nice interface that I enjoyed? As I’ve discussed with various friends, it used to be that if someone came to me and said “hey, I found this neat 3rd party client for ICQ! You should try it!”… I would respond with “why?” I mean the real client ruled. What happened? I never liked AIM’s, but it wasn’t “annoying”. Nowadays I loath having to bring up the real ICQ and AIM clients. I get bombarded with ads, a screen full of addons and a chat window that looks like the chat part of it was an afterthought. What happened? =( Almost makes me want to write a jabber client that behaves like ICQ -used- to. Of course, I’m not a Windows user, so why would I bother?
Anyway, I disgress. There are some odd differences between AIM and ICQ. For example, I put into place a connectionLost handler to trigger if the authenticator failed and booted you. (this typically happens on a failed password) I cleaned things up, severed connection with the Jabber session, and all was well. ICQ doesn’t like this. It triggers a connectionLost after every successful authentication. Cute, huh? This probably makes some sense somewhere… I’ll have to work this all out in a more sustainable fashion in the future.
For some reason the buddy icon that I upload does not appear to be triggering. It appears to upload and everything correctly. Gaim doesn’t appear to do anything different. However, ICQ5 is not seeing the icon. I’m in the process of installing gaim locally to see if the icon works correctly in the gaim implementation. Might have to do another packet dump and see what ICQ5 is theoretically asking for. Joy.
Updates in progress
I began the process of updating PyICQ to have PyAIM’s mods (at least, all those that apply) two nights ago. Going pretty quickly so far. There are some conflicting design decisions I need to work out in my head. Shouldn’t be hard, just need to sit down and do it. It actually seems that I ought to re-implement groupchat in PyICQ. Only problem is, I can’t prove whether it will work or not until I actually do it. Even if you flat out can’t do a groupchat with ICQ, there’s a chance you might be able to do it if you enable cross chat. I figure, I’m copying over code anyway, I might as well put that all back and pull it back out if I don’t need it/it won’t work.
So there’s some odd thing going on. If I run the oscardemo against ICQ, it runs, and it runs S L O W. I actually suspect this might have something to do with the chat room creation part. That seems to be where it slows to a halt for a bit. Either way, I wonder what’s going on with the slowness? I noticed that, whether ICQ or AIM I’m using, that using oscar.py seems to be slower with command line things than it does with the transports themselves. Isn’t that odd? I wonder if it has something to do with the reactor choice. oscardemo.py uses “default” which is apparantly depricated. =) Eh, I’ll work all that out later.