Development
I figure one of the best ways of describing the development of my "monkeys with candy floss" gallery software (if it can really be called that) is to first give a brief overview of what it does (and doesn't do) and then to detail some of the trials and tribulations faced while developing it.
Overview
First things first, MWCF is built using PHP and MySQL (you're all shocked I can tell). One thing it does slightly differently than anything I've built before is use an almot true represenation of the MVC design pattern; so there is only one entry point which is procedural and the rest is all object orientated. Unlike a lot of the development frameworks being released nowadays which think Ruby on Rails is akin to the Second Coming, MWCF doesn't use ActiveRecord for it's objects. I'm still of the persuasion that PHP can be a very good language for speedy websites as long as you're willing to make some trade-offs. PHP isn't truly object orientated yet and a lot of the nicer features of other OO languages either aren't present, don't work or don't work the way they should. So I use DB Mapper classes to mediate between database and objects which for the most part is pretty seamless.
MWCF runs on a meagre 4 database tables (versus Gallery 2's gargatuan 39), one for galleries, one for images one for users and one that stores possible user actions (that one technically isn't neccessary but nice to have around for the 3rd Normal Form freaks). All the thumbnails and images are stored in files and referenced from the database, no images are stored in blobs in the database. Users are given a username and password and a set of actions they can perform (add, edit, delete images and galleries and manage users).
Trials and Tribulations
Modified Pre-order
One of the database structures I'd been playing with before starting gallery was the Modified Pre-order Tree Traversal way of storing a tree structure in a flat file database. In theory, this means that you can store a tree like structure within a database without having to resort to "parent" fields which then does as many database queries as there are levels in a tree. The Modified Pre-Order theory is covered in a couple of articles which cunningly enough give you bugger all hard implementation for the nitty gritty details of things like deletion, moving of nodes and other such things. I'd pretty much conquered those omissions, however, when the gallery had been built and I was tuning queries, a problem came up.
To get the children of a node, you have to submit a very inefficient query which basically returns ALL of the children beneath a node, no matter the depth level. This is highly inefficient for something like the homepage, especially when you have a lot of subgalleries. Unfortunately the Modified Pre-order is magnificient for things like the breadcrumb trail at the top of pages (and for building the path to a file) all in one query. So I ended up using both modified pre-order AND a "parent" field for galleries, and only used the parent field for getting the immediate sub-galleries, and the MPO for everything else.
Thumbnails
Thumbnailing images is not something I'm a stranger to and have done it in a lot of forms for a couple of years now. The GD package bundled with PHP is awesome for batch jobs and doesn't require any external dependancies (beyond the required libraries of course). However, like with many things, a problem cropped up. Because GD operates in the same memory as the running PHP thread it is subject to a memory limit set either by the php.ini file, the server (Apache in this case) or the OS; to thumbnail it needed to load the entire image into memory then operate on it which presented a problem for large images which were just inexplicable ignored.
Enter ImageMagick. Because ImageMagick is run from the command line and not within the same PHP memory-space, it can operate on much larger files. A nice side-effect being that it can operate on a greater range of files and probable a lot more efficient than PHP and GD could manage. ImageMagick can also do some things which GD can't do, so all in all, it's a better choice. Unbeknowst to me of course, this had an interesting side effect.
STATIC Thumbnails
This sounds like the most simple decision you could imagine, but the choice of whether to store in the database the filename of the thumbnail or just to calculate it on the fly. Now, because the thumbnails and larger-sized images ae stored in wholly different directories, it meant I could leave the thumbnail filenames the same as the large files; none of this "tn_" prefixing nonsense.
Now, when using GD, you save your file by calling the very handy "imagejpeg" (or "imagepng" etc.) which will save to that file format and also reminds you what the filename should be. Of course, I forgot that when using ImageMagick, things work a little differently. Unless you force the output, it will thumbnail to whatever the input is. This isn't a problem if all your images are JPGs, however some of mine weren't. The few that were PNG managed to escape my notice, however when I tried to upload an animated GIF, well, things went pear-shaped. The thumbnail itself was animated, which didn't immediately twig me that there was a problem with the thumbnail output, just how ImageMagick dealt with images. After forcing the first frame ONLY to be used, the full depth of my stupidity was realised.
After much brainwracking, I came to the conclusion that there is no easy and cheap way to do extension swapping on the fly (bear in mind that we're talking case sensitivity, multiple image formats etc.). So I relinquished and stored the thumbnail filename in the database alongside the real filename. If you look around you can still see a bunch of PNG thumbnails and different cased extensions kicking about.
Colour Spacing
A very minor problem with dealing with images is dealing with colour spaces. Many many people won't know the difference between CMYK and RGB as most all images are RGB, but both ImageMagick and GD have issues with CMYK colourspaces (ImageMagick can be forced to RGB output) however the more fundamental issue is that some browsers don't support CMYK images even though they're valid images.
Random
As with any project there are a host of other minor things to deal with. For instance, a nice way to deal with gradiating user actions (so some people can add images but not galleries, some can add but not delete etc.). The obvious answer is to use a linking table, but that's far from elegant coding-wise, so the answer was to use a bitmask and "magic" numbers defining what a user can do. This works a charm as long as you bear in mind PHP's esoteric type-juggling.
Or for instance, how to accurately work out applicable sub-galleries. So do you count a sub-gallery as just one beneath the current level (the easy way) or do you only count a sub-gallery if it has images or another sub-gallery in it? The latter sounds the more useful, however you get into a problem when you have a long line of sub-galleries, and you add an image to the last sub-gallery, it could potentially "enable" a huge number of other galleries above it. Short way to deal with it: don't have empty sub-galleries and use the easy method.