10 Shared Thumbnail repositories #
In some situations it is desirable to have a shared thumbnail repository. This is a read-only collection of thumbnails that is shared among different users or different computers. For example a CD-ROM with images, could include the thumbnails for these images such that they do not need to be generated for every user or computer accessing this CD-ROM.
A shared thumbnail repository is stored in the directory whose files it should contain thumbnails for. The location for a shared thumbnail repository inside such a directory will be:
.sh_thumbnails/
Within this directory are the same subdirectories as in the global thumbnail directory.
.sh_thumbnails/ .sh_thumbnails/normal/ .sh_thumbnails/large/ .sh_thumbnails/x-large/ .sh_thumbnails/xx-large/ .sh_thumbnails/fail/
The meaning of these directories is identical to their meaning in the global directory.
Shared thumbnails use URIs relative to the thumbnail respository instead of absolute canonical URIs. This applies both to the URI used when generating the thumbnail filename using md5sum, as well as the Thumb::URI property. This is due to absolute paths not necessarily being consistent across different users of the shared thumbnail repository.
Given an original file at "/mnt/pictures/picture.png", the shared thumbnail repository would be located at "/mnt/pictures/.sh_thumbnails/". The repository would contain an entry for the URI "./picture.png". A relative thumbnail URI must be comprised "./" followed by a single path segment for the filename with canonical URI encoding applied.
For shared repositories whose access method does not provide a consistent mtime (or not even a consistent name), the creator may leave out the Thumb::MTime (or Thumb::URI) metadata items, as long as it has alternative means of determining freshness and removing stale thumbnail files. For example, when a shared thumbnail generator detects that a raw file and a compressed file are visually identical, it can use a hardlink to a single thumbnail file for two files that vary in their MTime, file name (thus URI) and size, as long as it includes neither of those metadata in the thumbnail file.
10.1 Creating thumbnails in a shared thumbnail repository #
A shared thumbnail repository should be considered read-only. A program should never add or update a thumbnail in the shared thumbnail repository. Such a repository should only be created on special request by the user. If a thumbnail is outdated or corrupt, a program should create a new thumbnail in the personal thubmnail repository, and not update the shared thumbnail repository.
If the user specific requested the creation of a shared thumbnail repository, the thumbnails can be created. Because the URI for shared images is possibly not constant, this means that the full URI can not be stored in the thumbnail. The URI field should, therefore, contain only the filename, and no directory parts. All other properties, however, should be the same as in the personal repository, including the size. The permissions for shared thumbnails should be the same as their original images.
10.2 Loading thumbnails from a shared thumbnail repository #
When loading thumbnails from a shared thumbnail repository, the personal repository has a higher priority. If a thumbnail exists in the personal thumbnail repository, this thumbnail should be used, and not the thumbnail from the shared repository.
There is one exception to this rule. If the thumbnail in the personal thumbnail repository is outdated or corrupt, the thumbnail from the shared repository should be checked. If this thumbnail is correct, the thumbnail in the personal repository can be deleted and the thumbnail from the shared collection can be used.
The lack of Thumb::MTime and Thumb::URI in a shared thumbnail does not automatically mark the thumbnail as invalid. The program may still opt to create a local thumbnail, but may prefer not to do so (e.g. because it would involve heavy network traffic).