.apm
file from http://www.arsdigita.com/acs-repository/index?&type=acs4x and install through Package Manager.
/serverroot/packages/photo-album-lite/tcl/photo-album-lite-init.tcl
/serverroot/packages/photo-album-lite/sql/photo-album-lite-create.sql
/usr/openwin/lib
[hint: check nsd-oracle
and /etc/shell-mods.sh
]
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).
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:
wherehttp://your.server.domain/package_instance_url/photo/type/photo_id/filename.ext
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
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].
/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
.
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.
2. Uninstall
SQL> update pa_photos set deleted_p = 't';
SQL> update pa_folders set deleted_p ='t';
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:
Implementation details:
aegrumet@arsdigita.com