SIPI basics
The media server SIPI
The Simple Image Presentation Interface (Sipi) takes care of storing, converting and serving image, audio and video files as well as other documents such as pdf files. It is designed to be used by all institutions that need to preserve high-quality images and to make them available online.
SIPI implements the International Image Interoperability Framework (IIIF), which aims at supporting interoperability between different image repositories. SIPI efficiently converts lossless between image formats while preserving the metadata contained in the image files. If images are stored in JPEG 2000 format, SIPI can convert them on the fly to formats that are commonly used on the Internet. SIPI is written in C++ and runs on Linux and Mac OS X. It offers a flexible framework for specifying authentication and authorization logic which is obtained by scripts written in the scripting language Lua. SIPI supports restricted access to images, either by reducing the image dimensions or by adding watermarks to the images.
Interaction of DSP-API and SIPI
If a file is requested from SIPI by e.g. an image link served by DSP-API, a preflight function is called. This function needs three parameters: a prefix, the identifier (the name of the requested file) and a cookie. All file links created by DSP-API use the project number as prefix. An example link from our incunabula project may look as follows: 0.0.0.0:1024/0803/incunabula_0000003328.jp2/full/2613,3505/0/default.jpg.
Based on the provided information, SIPI asks DSP-API about the permissions on the file in question of the current user. Therefore, the cookie is needed: it contains the current user's DSP-API session ID. Hence, DSP-API can match SIPI's request with a given user profile and tell SIPI the permissions this user has on the requested file. If the user has sufficient permissions, the file is served in full quality. If the user has only preview rights, SIPI serves a reduced quality of the file or integrates a watermark. If the user has no permissions, SIPI refuses to serve the file. However, all of this behaviour is defined in the preflight function in SIPI and not controlled by DSP-API. DSP-API only provides the permission code.
Thus, DSP-API and SIPI stick to a clear division of responsibility regarding files: DSP-API knows about the names of files that are attached to resources as well as some metadata and is capable of creating the URLs for the client to request them from SIPI, but the whole handling of files (storing, naming, organization of the internal directory structure, format conversions, and serving) is taken care of by SIPI.
When a user creates a resource with a digital representation attached to it in DSP-API either via the Graphical User Interface (GUI) or directly via the Application Programming Interface (API), the file is directly sent to SIPI to calculate a thumbnail hosted by SIPI which then gets displayed to the user in the browser. SIPI copies the original file into a temporary directory and keeps it there for later processing in another request. In its answer in JSON format, SIPI returns the path to the thumbnail, the name of the temporarily stored original file managed by SIPI, the mime type of the original file and the original name of the file submitted by the client. At the moment when the user wants to attach the file to a resource, the request is sent to DSP-API's API providing all the required parameters to create the resource along with additional information about the file to be attached. The file itself is not submitted to the DSP-API's API, but its filename returned by SIPI.