Photo Album Lite

Essentials

Version: 4.0.1a, Release date: 2000-12-20
This is the alpha release of the Photo Album Lite package.
This alpha version is not subsite-aware, so should be treated as a singleton.
This package assumes that ImageMagick and Oracle InterMedia are installed and properly configured on your system. For a few pointers see the Gotchas section below.
Quick Install:
1. Grab the .apm file from http://www.arsdigita.com/acs-repository/index?&type=acs4x and install through Package Manager.
2. Check for the correct path to ImageMagick in /serverroot/packages/photo-album-lite/tcl/photo-album-lite-init.tcl
3. Make sure that the aolserver user can write to the serverroot directory.
4. Check your InterMedia settings if you want to use search. See detail near the bottom of /serverroot/packages/photo-album-lite/sql/photo-album-lite-create.sql
5. Solaris only: make sure that your server's LD_LIBRARY_PATH contains /usr/openwin/lib [hint: check nsd-oracle and /etc/shell-mods.sh]
6. Restart your server.
7. Mount a package instance and go!

Introduction

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. The Lite name was also chosen to distinguish this package from an industrial-strength one currently under development at arsDigita, which will probably be called Photo Album.

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. Also, a moderately savvy hacker can add photos to someone else's folder in this alpha release.

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:

http://your.server.domain/package_instance_url/photo/type/photo_id/filename.ext

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.

Gotchas

1. Installation

This package requires ImageMagick. You can download it from the ImageMagick site at http://www.imagemagick.org.
You have to tell the server where ImageMagick lives. The package should be correctly configured for RedHat7 out-of-the-box. For everybody else, you can set the correct path by editing the pa_param values at the top of /serverroot/packages/photo-album-lite/tcl/photo-album-lite-init.tcl [Note: in later versions we will use ad_parameter, As It Should Be].
Solaris users need to add /usr/openwin/lib to the LD_LIBRARY_PATH. ImageMagick/Solaris requires a library called libdpstk.so. This may not be included in your aolserver's environment by default. If you use the standard aD architecture, you can set this variable in /home/aol32/bin/nsd-oracle.
The server root must be writable by the aolserver user. Image files are stored in the UNIX filesystem under the serverroot, so this directory must be writable by the user running aolserver.
The install script sets up a dbms_job to update the InterMedia index. This requires that your database user have the execute privilege on ctx_ddl. This privilege must be granted explicitly; granting through the ctxapp role alone will not work.
Remember to restart your server after installing and configuring the package.

2. Uninstall

You must delete all photos and folders through the web interface before uninstalling the package. This is a failsafe against unintentionally deleting content. Alternatively, you can run the following commands in SQL*Plus:
```
SQL> update pa_photos set deleted_p = 't';
SQL> update pa_folders set deleted_p = 't';
```
You need to manually remove the dbms_job. By default, the Intermedia index is rebuilt every 4 hours with a dbms_job. If you're observant, you will have noticed that the install script prints out a numerical id for the job. This is the job you want to remove. In any case, it is easy to look the job up like so:
```
SQL> select job from user_jobs where what = 'pa_rebuild_idx;';
```
You can then drop the job by running this script:
```
SQL> begin dbms_job.remove(the_job); end;
SQL> /
```
Automatic job removal will be added to the drop script in the next version of this package.
Create fake objects if acs_object.delete() fails. The drop script may fail to drop the pa_photo and pa_folder object types if there are any objects of those types lying around. Your first impulse might be to use acs_object.delete(). And it might work. If it doesn't work, it's probably because the extension tables--pa_photos and pa_folders--have already been dropped. Here is a quick and dirty way to fool the object system into doing the right thing: recreate straw-man pa_photos and pa_folders tables with just the primary key column, fill them with entries that have id's corresponding to the objects of the same type in acs_objects, and you're good to go.

The future

1. Easy stuff

Features:

Make the code subsite-aware.
Add thumbnails to the search results.
Handle zip files for uploading.
Add ability to change photo order.
Lots of little navigation improvements.
Lots more error checking.

Implementation details:

Automatic removal of the dbms_job.
Make the code that does the ImageMagick calls modular.
Use ad_parameter instead of pa_parameter
Allow photos to be stored outside the webroot?

Harder stuff

Deal with timezones intelligently.
Load image from URL.
Load a bunch of images from e.g. http://www.photoworks.com
Tag images with location.
Signed java applet for image uploading? Lots of work, but great payoff if people are willing to take the security risk (insane, I know). For ideas check out the crazy ActiveX thingee at http://photos.yahoo.com, or the simpler drag-and-drop interface at http://www.ofoto.com.

aegrumet@arsdigita.com