A few folks have dropped me email to ask about what I’m planning for RapidAlbum 2.0. As I’m still working thru’ some of the basic details, I’m a bit loathe to commit to what’s actually going to be in there but it does look (at the moment) as if it’ll be a ground-up rewrite. The basic code grew a bit organically during the alpha and beta phases of the 1.0 release and I really want to rewrite a lot of the core so that it’s more flexible (and maintainable).
The good news is that I’ve started on it. A lot of the projects that I work on for myself seem to need the same things over and over again. For example, MetaSync and RapidAlbum both need fairly extensive image metadata support and, until now, they’ve gone about that in a fairly separate way (MetaSync is Applescript Studio and RapidAlbum is obviously in cocoa).
In order to reuse as much as possible, I’ve started to strip out a lot of my existing code into general cocoa frameworks so that I can leverage them in lots of different projects. I should have done this a while ago but it’s not always easy to see the wood from the trees. This is what I’m busy working on right now.
I now have a standard metadata framework that will read image metadata from iPhoto, Aperture, MediaPro, Expression Media and the Finder into a common object structure. The goal here is to allow RapidAlbum to build smart web albums (i.e. it can interrogate iPhoto for all the photos in the “Santa Cruz” album) and to allow the next version of MetaSync (which I think will be called “Metal”) to synchronize between applications.
I’m hoping that once I have the basic support for other features (I need a general Inspector framework too), actually rewriting RapidAlbum will go really quickly.