April
The month of April was characterised by two main themes
Implementation of the IIIF Presentation API.
Bugfixing and refactoring
To the IIIF Presentation API more than first point among the developments. On the subject of bugfixing and refactoring a few background insights at the end of this digest.
While last month we reported about the IIIF Image API and its compatibility to version 2.1 we can announce this month that the Goobi viewer is compatible to the IIIF Presentation API 2.1.1. It doesn't matter whether the original documents are in METS/MODS, LIDO, TEI, EAD or another format. As soon as these can be displayed by the Goobi viewer itself, i.e. the metadata has been indexed by the Goobi viewer Indexer and saved in the Solr search index, IIIF Presentation Manifest files are automatically generated.
A download link for the manifesto of a work or object is available above the image display. For developers, further methods are available to integrate the URLs of the various manifests into their own ads:
The manifests can then be displayed in the Mirador or in the UniversalViewer, for example.
In the CMS it is now possible to link individual pages with works. This allows automatic linking to the corresponding page within the work display.
The URLs to uploaded media can also be easily copied. This makes the work easier especially if these media are to be used in the texts on CMS pages.
The METS and LIDO resolvers can now also be given URNs. Previously it was limited to factory identifiers such as PPNs or AC numbers.
For developers, the Javadoc as well as the JSDoc is automatically generated at each commit and published on Github Pages. The documentation is available at the following addresses:
The URLs can also be found in Goobi viewer Core's README.md.
There are always programming errors in software development. These are called "bugs", corrections are "bug fixes". There are bugs of very different kinds. Examples are syntax errors (a bracket opens but does not close again), loops that never end again or files that are read but never closed again.
But there are also features that don't scale well after a certain point. Does a digital library have 10, 100, 1000 or 10,000 unique visitors per day who work with the data for different lengths of time? A database query that is processed within a few milliseconds for 100 visitors can then take a few seconds at once for 10,000 visitors and multiple parallel queries. Here it becomes more difficult to define whether it is an error or a new requirement that did not exist a few years ago.
For us in the Goobi viewer team it is always important to be able to adjust something. If a developer can reproduce a behavior in his development environment, then we can also work on changing it. The solution is then completely different and the time that flows into it cannot be read off in source code. Sometimes it takes a day to recreate a behavior, a few hours to understand it, and then several hours to try out different solutions. In the end it is sometimes just a line of code that is different.
We in the Goobi viewer team work with various tools that allow us to quickly identify and fix bugs in development. These are mainly of a technical nature, but one of our tools is the so-called "refactoring". This process describes the tidying up of source code with constant functionality. It makes the code clearer or easier to understand. We always take the time to do this. A bit every month. This work is not visible to the outside world, there are no new features, buttons, ads, etc.. But they are very important for the continuous development of the Goobi viewer.
