Tuesday, June 12, 2007

Projects for the Banker

Given that I called my blog "The Flaming Banker" (in reference to the fact that I work for a bank and I start more than my fair share of flame wars), one would think I'd make a few more posts leaning toward the "flaming" part of the name, right? Well, apparently I'm incapable of doing too much of that. Every time I have something that I could rant about here, I end up distracted long enough that I'm no longer irritated enough to post it here. I just can't hold a grudge or stay angry for extended periods of time--don't get me wrong, that's almost certainly a good thing.

But enough of that. :) Let's get to the title of this post, shall we? Projects for the banker.

I recently, for some unknown reason, agreed to implement a feature in my listhandler plugin for libpurple. This feature would allow the importing of NotesBuddy exported buddy list files with a .dat extension. I spent a couple hours total on it before giving up on it as a useless, impossible task. My reasons for giving up on this were that I do not use sametime, nor do I have access to a server that provides the sametime protocol. The format was also completely incomprehensible to me.

I also received a patch for listhandler to implement the ability to export an XML list of aliases and then import said list without actually adding buddies to the list. I'm still undecided on this (mainly because I'm lazy and don't want to spend the time to fix the deficiencies I see in the implementation) but will probably rush to squeeze it in before Thursday, in hopes that we'll release the plugin pack to coincide with Pidgin 2.0.2.

The Pidgin FAQ...that's an interesting labor of torture and love. Luke Schierer simply does not have a block of time he can dedicate to sitting down and pouring a ton of documentation into the wiki at developer.pidgin.im. Nor does Stu Tomlinson, original author of the SSL-specific "FAQ." Stu nominated me to transcribe the SSL information to the wiki, which I was crazy (stupid?) enough to do. It took several days, on one of which I lost several hours' work and had to reconstruct it, but I managed to get it done. Following that, I noticed that what Luke had managed to put in the wiki was a bit anemic compared to the old FAQ. As I said, he simply does not have enough time to do all the bajillion projects that have resulted as a side effect of the name change and the migration away from Sourceforge. Given these two facts, I decided to pitch in and help beef up the FAQ on the wiki with more useful info. Amazingly, in just a few short hours (spread across a few days) I managed to migrate over half of the old FAQ to the wiki. I still have more questions I need to move over, and a few I think I need to add, but the most important stuff is there.

The downside to Pidgin having a wiki now is that anyone with an account can edit the wiki. I'm not so sure I like this idea. I was opposed to it from the start, then grew indifferent, and now am starting to come back to the opinion that it's not worth the trouble. As I mentioned, I spent several hours on the FAQ transcription. A couple days after I made my last changes, someone came along and butchered the careful wording that both I and Luke had previously placed into some questions, and added a new "question" that was completely incomprehensible. It took me literally half an hour to figure out what the person was trying to communicate. I have, however, fixed the offending entries.

I'm not going to bother lobbying for more restrictive wiki permissions, as I know it's a losing battle. There are apparently benefits to this approach that I'm not seeing right now. I've also started enough arguments within the Pidgin camp, and don't particularly feel like starting another.

And now let's get to the mother of all projects--Guifications 3. Gary Kramlich created this brainchild before I even became involved with his projects, and it's still in development. While Gary is frustrated with this (and rightfully so, as the rest of us developers have been mostly lazy bums in the process--no offense intended), he and I both realize this is probably for the best in the long run--as Gary has progressed, he's found some major flaws in his initial design that he's able to fix now, while we're still pre-alpha and mostly unusable.

Now, Gary would be quick to discredit my classification of myself as a "lazy bum," as he did last night in an IM conversation when I called myself useless. He does correctly point out that I have done a bit here and there and also taken some of the administration load from him, which helps him because it frees more of his time to work on the hard stuff in Guifications 3. I also try to take on the support role as much as possible when users come to us with issues involving Guifications 2 and the plugin pack.

At any rate, however, Gary decided that he needed to change some API by renaming GfFeedPool to GfFeedManager. He also needed to design a new API component, so he asked me to handle what I could of the Pool -> Manager transition. I spent a couple hours on this, more than Gary would have, I'm sure, but the end result is I did finish the conversion. I also found a few issues that resulted because Gary had split some functionality out of gflib and into gflib-ui, but had forgotten to update #include statements. Because of this work, I built and installed over half of Guifications 3, which roughly corresponds to how many of its modules are even remotely close to hackable, usable, or functional.

After all this discussion of Guifications 3, I'm sure some people are going to wonder what Guifications 3 is and why it's taken well over two years to develop while still not producing a usable "product." Without giving too much away, I'll try to answer that here. Guifications 3 is a modular framework for notifications, similar in purpose to libnotify and Growl, but with a much broader scope. We make heavy use of dbus by default and will support xmlrpc and a variety of other communication methods. And yes, that means that we're expanding our horizons beyond Pidgin. Far beyond. Yes, I know that's horribly vague, but until we've reached "hackable" there's not much point in laying all the cards out.

Also, since my last post I've had the pleasure of talking with Jennifer twice. She seems to be doing better than she was, but seems to be still very deeply hurt over the events that led up to our five-plus-hour conversation. I'm glad to see, though, that she is taking a sensible route on the matter and somewhat distancing herself from the situation. In the end it will make a huge difference for her, as she'll know some different aspects of life she hasn't yet explored. She will end up a much stronger person because of this, and I'm sure I'll find myself respecting her even more than I do already. Indeed, this too is intentionally vague, as I do wish to protect her privacy and avoid causing her any pain myself.

At any rate, I now need to go to bed.