I’ll be posting a few notes over the next month or two about upcoming changes. I don’t really want to post too much on this as things are still in flux but I thought it’d be worth pointing out the areas that I’m rewriting completely and know will change.
A problem area for the current RapidAlbum code is image handling. Right now, when RapidAlbum generates scaled images (such as thumbnails and smaller main images), it generates them to a cache directory in the user library. This sounded like a good idea at the time but it’s led to some subtle and awkward bugs.
The image handling for RapidAlbum 2 is going to work like this –
Thumbnails and sized images will be stored in the RapidWeaver document sandwich. I’m going to offer the ability to store the original image in the document sandwich too so that folks who don’t want to keep the original after they publish will have a backup. The current behavior, whilst very useful for a lot of folks, has caught a few users out. You’ll be able to change whether a local copy is kept or not as an album setting.
Original files will be tracked better on disk. Right now, when you move original images around, RapidAlbum gets confused. I’ll be tracking image paths a lot better in the new code.
Local copies of scaled images offers the potential ability to allow image warehousing. This is something I’m definitely working on. Whether it makes the first 2.0 release or not depends on how easy it is to add network browsing but these changes open up this possibility.
Images will be scaled at import and when the parameters change. Right now, they’re scaled on publish/export which causes all sorts of problems during generation (as I need some of the thumbnail and scaled image info before building the actual HTML for the pages).
All of these changes should make RapidAlbum a lot more reliable and robust for image management.