This is the week 07 status report for AudioMan and its subprojects.

What was done last week

When you're dealing with metadata you're dealing with files, so you need files for unit tests. For the last two years AudioMan has had code that gets a file from a test directory, copies it to the temp directory and then returns the temp file for testing so the original test file isn't modified. It's very handy but it wasn't made for plug-ins (and the boundaries they enforce). This week I rewrote the code so that any plug-in's tests could grab a temporary test file.

I made up an abstract class called Operation for application-level logic code that is squeezed between UI and Durham. Like JFace's Action class, subclasses of operation implement the run() method to specify what the operation does. Then like a Thread object the UI code starts the operation with the start() method, which calls the operation's (protected) run() method in a new thread. The threading code is in the Operation abstract superclass and can be changed without affecting the many concrete operation subclasses. The next step will be to integrate Operation into RCP's Job support and show progress in the UI for all of the currently running operations.

A lot of progress was made on the Collection Browsing perspective. Users can include files or whole directories (recursively) into their collection, browse the collection and edit file metadata. AudioMan2 is quickly catching up to where AudioMan1 left off. I took a vacation from work last week so I had far more time to work on AudioMan than usual and progress was substantial.

I'm debating with myself whether to release AudioMan soon. True, it's functional and people could edit tags and browse with it but it's not doing anything revolutionary. People can do that in iTunes. I think I'll wait until AudioMan does something special before I take the time to release it.

I know this goes against the release often mantra but on a one person project releasing software is time expensive. It's not time expensive to generate a release package -- that takes 90 seconds. Tweaking the quality level up to my release standards takes a lot of time, a problem I had with AudioMan1. I spent a lot of my time on AudioMan1 preparing releases that few people used, just to satisfy release often. Lesson learned; I think I'll wait a bit longer.

If you really want to see what AudioMan2 is doing you can check out the source code. I try my best to keep the repository stable but I wouldn't call it release quality.

---

I implemented the "audio content category" I talked about last week which is a collection of audio content type definitions. Right now I've only defined the MP3 content type but when I add support for other audio content types (OGG, WMA, FLAC, SHN, etc) I'll just add them to the audio content category. Then they will just work in AudioMan (browsing, editing, etc) with no other changes necessary since AudioMan deals with the audio content category and not specific content types. I'm glad it worked out -- it made the AudioMan code much simpler.

It's also not that difficult for third parties to create their own content types and content categories. Durham is shaping up to offer good metadata support for Eclipse and Rich Client Platform (RCP) applications and AudioMan is taking full advantage of it.

AudioMan is also taking advantage of the RCP itself. Construction of AudioMan's GUI was far simpler this time around, thanks to the pre-constructed workbench and views the RCP offered. The amount of UI code I had to write decreased, which reduces the manual testing burden. Music to any PM's ears.

New things to do

• Use the new build machine for CVS and nightly builds
• Mac: package products in a dmg'd bundle
• Support for adding backup discs to the collection
• Start work on the Backup Management Perspective
• Investigate collection persistence between sessions: Hibernate.