Thumbnail service notes

Owned by Former user (Deleted)
Last updated: Feb 12, 2008Version comment
2 min read

High-level options

A major behind-the-scenes addition to the Image Gallery in Phase 2 is use of real thumbnail images. (The Phase 1 design downloads full-sized image files for each "thumbnail" on the screen and relies on the browser to resize them.) Although this is a very common need, there's not yet any widely agreed upon convention for meeting it.

Option 1) Keep thumbnail files in the digital repository with the original image file

PRO

  • Makes intuitive sense.
  • Allows for shared access to thumbnails.
  • Thumbnail images are most efficiently served if they're static files, and it's possible that our only supported way to store static files will be through a repository interface.

CON

  • Digital repositories tend to be tuned for heavyweight institutional archiving rather than for quick lightweight access. Thumbnails need to be quickly obtained and easily deleted and regenerated.
  • Digital repositories tend to be tuned for centralized storage of large files. Thumbnails don't take much storage space.
  • Thumbnail images tend to have far different access requirements than original media in a digital repository.
  • There's no de facto standard to associate thumbnails with source data, even among JSR-170 repositories.
    • An experienced developer on the Jackrabbit mailing list suggests associating a thumbnails "nt:folder" of files with the image "nt:resource".
    • The Alfresco Thumbnails add-on uses more idiosyncratic types.
    • Magnolia dynamically generates thumbnails from the stored source image.
    • DSpace uses a Media Filter, which I believe might also be dynamically generated.
    • Fedora shows some demonstration objects with their own thumbnail scheme, but I don't know if anyone's using something similar in production. The Elated front end application for Fedora actually generates and stores its own thumbnails in its own file system.

Option 2) Keep thumbnail files associated with their gallery collection

PRO

  • Also makes intuitive sense. (smile)
  • Appropriately optimizes access, regeneration, and authorization.

CON

  • If our only way to the file system is through a repository API, we end up using two flavors of repository, storing thumbnail data in the DB, or taking the dynamically-generated approach (hopefully with good caching by the server). These choices all seem slightly embarassing, but I'm hard-pressed to say exactly why.

High-level resolution

A Thumbnail Service facade, of course. TBD: its initial implementation.