<html>
<head>
<title>Photo Album Lite</title>
</head>
<body bgcolor=ffffff>
<h2>Photo Album Lite</h2>
by <a href="mailto:aegrumet@arsdigita.com">Andrew Grumet</a>
<hr>
<h3>Essentials</h3>
<ul>
<li>Version: 4.1.1 beta, Release date: 2000-02-28
<li>This is the 4.1.1 beta release of the Photo Album Lite package. <small>(<a href="index-4.0.1.html">view 4.0.1 documentation</a>)</small>
<li>This version requires acs411, and will be buggy (if functional at all) on earlier versions of acs.
<li>A substantial number of new features have been added. <small>(<a href="changelog.txt">view changelog</a>)</small>
<li>4.0.1 users need to <a href="upgrade-4.0.1-4.1.1b.txt">run an upgrade script in SQL*Plus</a>.
<p>
<li>The next version will have real documentation (I promise!)
<p>
<li>This package assumes that <a href="http://www.imagemagick.org">ImageMagick</a> and Oracle InterMedia are installed and properly configured on your system. For a few pointers see the <a href="#gotchas">Gotchas</a> section below.
<li>Quick Install:
<ol>
<li>Grab the <code>.apm</code> file from <a href="http://www.arsdigita.com/acs-repository/index?&type=acs4x">http://www.arsdigita.com/acs-repository/index?&type=acs4x</a> and install through Package Manager.
<li>Check for the correct path to ImageMagick in <code>/serverroot/packages/photo-album-lite/tcl/photo-album-lite-init.tcl</code>
<li>Make sure that the aolserver user can write to the serverroot directory.
<li>Check your InterMedia settings if you want to use search. See detail near the bottom of <code>/serverroot/packages/photo-album-lite/sql/photo-album-lite-create.sql</code>
<li><em>Solaris only:</em> make sure that your server's LD_LIBRARY_PATH contains <code>/usr/openwin/lib</code> [hint: check <code>nsd-oracle</code> and <code>/etc/shell-mods.sh</code>]
<li>Restart your server.
<li>Mount a package instance and go!
</ol>
</ul>
<h3>Introduction</h3>
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.
<p>
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.
<p>
This package is not an image manipulation program. Though the
underlying software makes use of the powerful <a
href="http://www.imagemagick.org">ImageMagick</a> libraries, we will
mostly shield the end user from these capabilities (perhaps adding
rotations in a later release).
<h3>Why Photo Album <em>Lite</em>?</h3>
I'm calling this package Photo Album <em>Lite</em> 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 <em>-02/2001</em>].
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 <code><a href="http://www.arsdigita.com/acs-repository/one-version?version_id=1192">photo-album package</a></code>.
<p>
So why use <code>photo-album-lite</code>?
<ul>
<li>Simple, intuitive user interfaces
<li>A full host of useful features, including:
<ul>
<li>Bulk file-upload.
<li>Bulk photo naming and dating.
<li>Re-ordering of photos within a folder.
<li>Photos are commentable.
<li>Photos can be viewed as a slideshow.
<li>Up-to-the minute activity summaries on the index page.
<li>Fulltext search of photo names, authors, and captions.
<li>Photos are available in up to 3 sizes.
<li>Package is fully subsite aware.
</ul>
</ul>
<h3>Application Design</h3>
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
<code>acs_object</code> 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.
<p>
The tables are laid out so that every photo must be a part of exactly
one folder. Or, in data-modeler speak:
<blockquote><em>Each folder may contain zero or more photos.<br> Every photo must belong to one and only one folder.</em></blockquote>
<p>
Images are served from a virtual URL having the following format:
<blockquote><pre>
http://your.server.domain/package_instance_url/photo/type/photo_id/filename.ext
</pre></blockquote> where <code>type</code> is <code>orig</code>
(original size), <code>med</code> ("medium"-sized, default
is 400pixels in height) or <code>thumb</code> (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.
<p>
The photos are themselves are stored in the Unix filesystem (i.e. not
as BLOBS), in a subdirectory of the server root, as
<code>photo_id-type.ext</code>. I experimented a bit with
InterMedia's <code>ORDImage</code> 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 <code>process</code> method) produces notable image
degradation.
<p>
<strong>When an image is deleted through the web interface, all associated
image files are deleted from the filesystem.</strong>
<a name="gotchas">
<h3>Gotchas</h3>
<h4>1. Installation</h4>
<ul>
<li><strong>This package requires ImageMagick.</strong> You can download it from the ImageMagick site at <a href="http://www.imagemagick.org">http://www.imagemagick.org</a>.
<li><strong>You have to tell the server where ImageMagick lives.</strong> 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.
<li><strong>Solaris users need to add <code>/usr/openwin/lib</code> to the LD_LIBRARY_PATH</strong>. ImageMagick/Solaris requires a library called <code>libdpstk.so</code>. 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 <code>/home/aol32/bin/nsd-oracle</code>.
<li><strong>The server root must be writable by the aolserver user.</strong> Image files are stored in the UNIX filesystem under the serverroot, so this directory must be writable by the user running aolserver.
<li><strong>The install script sets up a <code>dbms_job</code> to update the InterMedia index.</strong> This requires that your database user have the <code>execute</code> privilege on <code>ctx_ddl</code>. This privilege must be granted explicitly; granting through the <code>ctxapp</code> role alone will not work.
<li><strong>Remember to restart your server after installing and configuring the package.</strong>
</ul>
<h4>2. Uninstall</h4>
<ul>
<li><strong>You must delete all photos and folders through the web
interface before uninstalling the package.</strong> This is a failsafe
against unintentionally deleting content. Alternatively, you can run
the following commands in SQL*Plus:
<blockquote><pre>
SQL> update pa_photos set deleted_p = 't';
SQL> update pa_folders set deleted_p ='t';
</pre></blockquote>
<li><strong>Use
<code>cleanup-failed-drop.sql</code> if the drop script
fails.</strong> The drop script may fail to drop the
<code>pa_photo</code> and <code>pa_folder</code> object types if there
are any objects of those types lying around. Your first impulse might
be to use <code>acs_object.delete()</code>. And it might work. If it
doesn't work, it's probably because the extension
tables--<code>pa_photos</code> and <code>pa_folders</code>--have
already been dropped. The script
<code>/serverroot/packages/photo-album-lite/sql/cleanup-failed-drop.sql</code>
fools the object system into doing the right thing by: recreating
straw-man <code>pa_photos</code> and <code>pa_folders</code> tables
with just the primary key column, filling them with entries that have
id's corresponding to the objects of the same type in
<code>acs_objects</code>, re-running <code>acs_object.delete()</code>
to delete the objects, and re-running
<code>acs_object_type.drop_type()</code> to delete the types.
</ul>
<h3>The future</h3>
Features:
<ul>
<li>Tag images with location.
<li>Deal with timezones intelligently.
<li>Add thumbnails to the search results.
<li>Lots of little navigation improvements.
<li>Load image from URL.
<li>Load a bunch of images from e.g. <a href="http://www.photoworks.com">http://www.photoworks.com</a>
<li>Signed java applet for image uploading. For ideas check out the crazy ActiveX thingee at <a href="http://photos.yahoo.com">http://photos.yahoo.com</a>, or the simpler drag-and-drop interface at <a href="http://www.ofoto.com">http://www.ofoto.com</a>.
</ul>
Implementation details:
<ul>
<li>More error checking.
<li>Make the code that does the ImageMagick calls modular.
</ul>
<p>
<hr>
<address>
<a href="mailto:aegrumet@arsdigita.com">aegrumet@arsdigita.com</a>
</address>
</body>
</html>