Photo Album Lite

Essentials

Version: 4.1.1 beta, Release date: 2000-02-28
This is the 4.1.1 beta release of the Photo Album Lite package. (view 4.0.1 documentation)
This version requires acs411, and will be buggy (if functional at all) on earlier versions of acs.
A substantial number of new features have been added. (view changelog)
4.0.1 users need to run an upgrade script in SQL*Plus.
The next version will have real documentation (I promise!)
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 [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?

Simple, intuitive user interfaces
A full host of useful features, including:
- Bulk file-upload.
- Bulk photo naming and dating.
- Re-ordering of photos within a folder.
- Photos are commentable.
- Photos can be viewed as a slideshow.
- Up-to-the minute activity summaries on the index page.
- Fulltext search of photo names, authors, and captions.
- Photos are available in up to 3 sizes.
- Package is fully subsite aware.

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:

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 package parameters using the acs admin pages.
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';
```
Use cleanup-failed-drop.sql if the drop script 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. The script /serverroot/packages/photo-album-lite/sql/cleanup-failed-drop.sql fools the object system into doing the right thing by: recreating straw-man pa_photos and pa_folders tables with just the primary key column, filling them with entries that have id's corresponding to the objects of the same type in acs_objects, re-running acs_object.delete() to delete the objects, and re-running acs_object_type.drop_type() to delete the types.

The future

Features:

Tag images with location.
Deal with timezones intelligently.
Add thumbnails to the search results.
Lots of little navigation improvements.
Load image from URL.
Load a bunch of images from e.g. http://www.photoworks.com
Signed java applet for image uploading. 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.

Implementation details:

More error checking.
Make the code that does the ImageMagick calls modular.

aegrumet@arsdigita.com