Today marked the end of the single-account iteration for the VOIP front-end project. Today was mostly taken up with refactoring, testing, and generally cleaning up the single-account stories. The refactoring was pretty intensive, lots of common code factored into a small set of common, logically meaningful base classes, APIs for what seemed like different things way-back-when unified as they now are obviously just the same operations applied to different types of objects, that kind of thing.

What struck me, however, was that I'd gone through all of the single-account stories save two: "deactivate an account" and "reactivate an account". Pretty big stories, and they'd never been hooked up in the interface or tested (though all the parts of it save deactivating a whole account are tested).

I even have spike-test code that deactivates a SIP account and lets the back-end clean up after us, but nothing that took the account apart in a structured manner, disabling each active feature, and then the account. Nor did I have anything which tried to re-enable an account after such a deactivation.

Still, this should be a piece of cake, all the pieces are known to work, it's just a matter of making sure they all work together... oops. For some silly reason the SOAP/WSDL disabling method, which worked fine from tests or the command-line, was getting the wrong namespace when run within the script that disabled each feature and then called the disabling method. Burned quite a bit of time on that before I discovered that it was one of those cases that needed late binding of the name to take advantage of Dan's hack to allow multiple namespaces (even though it's in the first namespace).

Okay, so the "off" switch worked. Let's build an "on" switch, flip it a few times and move onto the next iteration... oops. I'd put off thinking about the problem of service dependencies. The UI had been structured in such a way that dependencies were automatically resolved by the "thing you were working on". There was no need for dependency resolution, but now I had the potential to have a forwarding feature activating the back-end before the active voicemail feature was present (you "forward" to voicemail when you're busy, offline, or don't answer the phone).

Don't get me wrong, I love dependency resolution, I've got mutliple topological sort mechanisms and there's nothing I like more than a chance to pull them out and play with them... but we're on a deadline here. So, I punted again, moving the common-resource setup after all feature setup during activation/deactivation so that the shared resources always get pointers to already setup/cleaned-up feature values.

Anyway, the iteration is complete, I've already done quite a lot of work on the next iteration (the multiple-account, hardware and restricted-access stories)... in fact, most of the multiple-account stories are done (save the moving of features among accounts) and I've done quite a bit on the hardware stories already.

Tim and Selena dropped in with Istra earlier. They brought some recordings of various lectures for me :) . Yay!