Until now, Loris pulls images using an HTTP resolver. It stores the image binary in a cached directory, in addition to the particular IIIF image tiles it caches. This has been okay, but it results in a duplication of images on the server (barring a dedicated Loris server), and is slower as it must "pull" that file from Fedora.
A long time ago, we flirted with the idea of inspecting the Fedora dataStore and accessing datastreams directly. A bit of work, and it's feeling stronger. The branch above is a working prototype of sniffing out fedora datastreams and creating symlinks. If it goes into production, requires the following changes in the Vagrant build:
use the FileSystem (FS) Resolver in Loris, completely bypassing our custom Fedora resolver
add configurations to Ouroboros for symlink directory, e.g. /var/cache/ouroboros/fedora_binary_symlinks
visit the idea of removing fedora: prefix to IIIF image_id, as we would just strip that anyway in the lorisProxy
it was only ever used to trigger the fedora resolver in Loris
Branch: https://github.com/WSULib/ouroboros/tree/fbspy
Until now, Loris pulls images using an HTTP resolver. It stores the image binary in a cached directory, in addition to the particular IIIF image tiles it caches. This has been okay, but it results in a duplication of images on the server (barring a dedicated Loris server), and is slower as it must "pull" that file from Fedora.
A long time ago, we flirted with the idea of inspecting the Fedora dataStore and accessing datastreams directly. A bit of work, and it's feeling stronger. The branch above is a working prototype of sniffing out fedora datastreams and creating symlinks. If it goes into production, requires the following changes in the Vagrant build:
/var/cache/ouroboros/fedora_binary_symlinks
fedora:
prefix to IIIFimage_id
, as we would just strip that anyway in thelorisProxy
fedora
resolver in Loris