It's been a while since I've posted here, and a lot has happened.

Adium

I did end up joining the Adium project, and I have been working on it. I haven't touched the iChat plugin, though - plans changed.

First, I wrote a crude Jabber plugin. I stole the acid library from the people who made the nitro client for OS X. It was really easy to work with - they've got a nice class structure, and they use a cool trick to parse the XML. They've got some factory code that returns different subclasses of XMlNode based on some xpath queries, so it just pumps out JabberMessage objects with very little code. It's really slick. This was fun code to write, and the acid/nitro people were pleasant to work with.

But...that's not what we've been working on lately. Christian Hammond has put a lot of work into separating gaim into libgaim and gtk-gaim, so he can make a qpe-gaim for handheld devices. We stole that code and a few of us have been writing a plugin around it. It's further along. It can handle sending/receiving, buddy icons, away messages (through a horrible kludge), idle times, etc. This is all for Oscar, but most of the code is in a generic class we can subclass for other protocols as well. And gaim supports a lot of protocols.

One little snag was that the Cocoa and glib event loops don't really fit together. Qpe-Gaim and Adium use a 10-ms repeating timer to poll for glib events. That drains my poor laptop's battery life. So I sent a patch to the gaim people that generalizes the event handling through a callback structure. With an adapter, it fits into Cocoa. I discovered NSFileHandle can't indicate write availability, so I wrote this class to have more flexible select() stuff from Cocoa. Anyone else need to test for IO availability? It's general code. I've seen a few requests for this on mailing lists, so maybe I'll see if I can talk the OmniFoundation people into including it or something. Update: Bob Ippolito pointed out that CFSocket can now do write notifications. So I'll likely be converting the Adium code to use that. But at least I got something out of it - it was good practice to write that sort of event loop code, since atoms will need a write of that sort of thing. (Its asynchronous notification code really blows now. I'm looking into libevent or liboop but will likely end up writing something myself.)

Not sure if I'll keep the separate Jabber plugin around or not. gaim has Jabber support, but Jabber is Not Like All The Others. Even with subclassing, it might end up being less code / more seamless to go with acid for that.

We recently discovered the leaks tool for OS X. So in the last couple days Adium has gone from hemorrhaging memory badly to being pretty tight. There are a few small leaks still reported, but I'm wondering if they're Panther bugs.

Thanks to whoever mentioned headerdoc when I asked about API docs before (sorry, I forgot the screen name). Haven't used it much, but I still intend to.

Strange little incident: my ISP pointed out to me that last month my server used 7GiB more bandwidth than usual. The culprit turned out to be a program a friend had installed on his account that does the Adium commit statistics. Apparently it's really inefficient - he was running it hourly, so it must have pulled about 10MiB per run from the SourceForge servers. So I suspended it and we've been looking into alternatives. I wanted to rsync it and run it on a local copy of the repository, but unfortunately SourceForge just has day-old tarballs of the repositories. So we're either going to uncompress the tarball on their server daily - using about 20 MiB of our 100 MiB allocated - and rsync it, or just reduce it to running once per week, which is a more reasonable ~40MiB/month of bandwidth.

atoms

Recently I resurrected my atoms project and have been playing with it. I used to have some really complex, slow code to handle signals correctly. (Which is a harder problem than most people realize - their code just doesn't work in all cases.) I rethought what I'm trying to do and realize the brand-new C++-safe cancellation support in Fedora Core 1 does most of what I want, and is being standardized. So I ripped out a lot of code, and I'm much happier with it now. This is really limiting my portability - the only other platform I've found where this test passes is a Tru64 machine I access through Compaq Test Drive. But it will improve. Until it does, some features of my library will just only work on a select few platforms.

The build system for atoms is getting frustrating. I want to use automake's dependency generation code and libtool, but I don't want to use all of automake. It's just such a mess - make didn't do it, so they added shell scripts, then they added m4 / a whole bunch of macros (autoconf), then they added autom4te (wrapper around m4), then they added automake (some Perl, more autom4te) and libtool. There's so much code there, and it's so convoluted. And it doesn't even work well - their current best practices suck. (They've talked about implementing the ideas in that paper, but so far it's just "in theory, you should be able to write a correct Makefile with automake...if you figure out how, let us know" in the documentation (paraphrased)). Plus, most of it doesn't apply to me - I'm writing a build system for modern C++ code. If a platform doesn't support ANSI C prototypes, it's sure as hell not gonna run my code. I've looked into jam, but I don't think it's quite what I want, either. I'm tempted to write a fresh system in Python, but I know I shouldn't. I have a bad habit of starting one project, finding something it depends on that I don't quite like, working on that for a while, and never really finishing either. So I'm trying to resist. (How do other people resist this urge?)

xmldb

I looked through my search logs and discovered there does seem to be some interest in my xmldb stuff. So maybe next weekend (after this round of midterms is over), I'll finish up my improved projects pages, package my code, submit it to freshmeat, and see what happens.

Work

Our new, shiny redesigned personnel system is in active use now, and has been for a while. It's great - it actually gives people friendly error messages (There's already someone with that SSN) or, if all else fails, pops up a bug report dialog. (Which fills in some fields from the form name, error ID, trigger block/item, etc, so we get more useful information than "My Oracle is broken.") And the schema is much more pleasant to work with. It's been a success, even if there were more initial bugs than we'd hoped for. I'm not even really working on it anymore - my friend/roommate/coworker is doing most of the maintenance on it now.