To be honest, when I set up the blog for this project, I didn’t think I’d have to add overmuch content, after all the actual coding was complete and all that remained was to write the final report and accept the cheers of the crowd. Alas for my naive optimism. When I first started writing the AFS stores and conduits many years ago, there were two perl modules available for accessing AFS, AFS which provided an interface to the AFS programming APIs and AFS::Command which ran the equivalent AFS shell commands and munged the output into various classes of objects. At the time when I sought guidance on which module to use, the vast majority recommended the programming API. After all the output from a command was far more likely to change than the programming interface right?
So I wrote the Stores and the Conduits and it went fairly smoothly despite some idiosyncrasies such as there not being a direct equivalent to pts listentries resulting in me having to run the command in a shell and slurp up the output, rather as AFS::Command would have done. The real issue came when writing the test suite. After all, you don’t want the code you’re testing rampaging through your production cell changing things willy-nilly. It took a long time to decide what the right answer was (longer than it took to write the code to be tested in the first place) but eventually, functions to emulate the required pts, fs and vos commands were written and the Test::MockObject module used to run these fake functions in place of the real ones. Once again, this worked pretty well and as I said at the top of the page, it was looking like this puppy could be finally signed off. Once small problem though. The AFS module hadn’t been updated for a long time and wouldn’t work with the next kernel update on the horizon. We considered making the necessary updates to the module ourselves but decided it would be too much work. So there was no alternative, eveything I’d written needed to be rewritten to use AFS::Command which was now, by consensus of the AFS great and good, the recommended way of doing things anyway. With a heavy sigh, I reached once more for the Camel book…
This has now been mostly done. The Store and Conduit code have been rewritten and tested and the pts test suite is now working again as well. One big advantage of using AFS::Command, which makes me wish I could hop into a time machine and tell my younger self to use AFS::Command from the start, is that when creating the initial object, one of the arguments you can give it is the location of the binary for vos, pts or whatever. This means that Test::MockObject is no longer required, you can simply point the AFS module at your test code. All that now remains is to port the AFSVL test suite across and this project will finally be done!