Photo Album Lite

by Andrew Grumet



The Photo Album Lite package provides a way for users to share digital photos with their friends and family. Photos can be uploaded and collected into folders (think: rolls of film), and then displayed back either as thumbnail images, medium-sized images, or at the original size.

This package is intended for novices, both to photography and computers. Throughout the package, emphasis is placed on simplicity of interface and minimizing the number of clicks needed to achieve the desired function. Only a small number of fields are stored for each photograph; these fields are filled out while looking at the image, after upload.

This package is not an image manipulation program. Though the underlying software makes use of the powerful ImageMagick libraries, we will mostly shield the end user from these capabilities (perhaps adding rotations in a later release).

Why Photo Album Lite?

I'm calling this package Photo Album Lite because it is intentionally light-weight. The permission model, for example, is rat-simple: everybody can look at every photo, and only the photo's owner can modify or delete it [Note: we have added a permissioning backend but kept the user interface simple -02/2001]. As another example, we do not provide a full filesystem-like hierarchy of folders, but instead store folders one-level deep. Finally, we do not provide any provisions in the backend or user interface for revisioning or workflow ala ACS Content Repository. Users interested in these features should consider using the photo-album package.

So why use photo-album-lite?

Application Design

I tried to keep this package pretty uncomplicated. The package creates two tables, one for storing photos and one for storing folders. Both of these are extension tables for acs_object which generates a certain amount of overhead, but I did it with the idea that I may actually do some real permissioning before long. For now, all photos are publicly viewable but can only be modified by the person who created them.

The tables are laid out so that every photo must be a part of exactly one folder. Or, in data-modeler speak:

Each folder may contain zero or more photos.
Every photo must belong to one and only one folder.

Images are served from a virtual URL having the following format:

where type is orig (original size), med ("medium"-sized, default is 400pixels in height) or thumb (thumbnail, default is 100pixels in height). There is currently no link to the original size image from the web interface, since images with heights > 400pixels are too big for most computer screens. In any case this is easy to add and will happen before long.

The photos are themselves are stored in the Unix filesystem (i.e. not as BLOBS), in a subdirectory of the server root, as photo_id-type.ext. I experimented a bit with InterMedia's ORDImage type but it doesn't deliver quite enough oomph to justify the performance hit we'd take from storing everything in the database. More specifically, scaling an image down (using the process method) produces notable image degradation.

When an image is deleted through the web interface, all associated image files are deleted from the filesystem.


1. Installation

2. Uninstall

The future

Features: Implementation details: