Introduction

At the University Library Frankfurt, we currently host 21 OJS journals, with more to come. Since we apply a strategy that runs only a single journal within an OJS instance, we have to maintain 21 different OJS instances. In order to maintain and manage this multiplicity, we found it important to come up with structures on the server and helper tools.

Especially the process of updating a journal instance can be quite tedious, since it involves multiple manual steps and can cause problems when forgetting something in the process. Due to these manual steps, the upgrade of a single OJS instance can take up to 20 minutes – and longer, if something doesn’t go according to plan.

In the first post of this series, I looked at how to achieve parallel execution in Python using multiprocessing pools and discussed how this is unsuitable with WSGI-based web frameworks because WSGI only allows the web server to create new processes, not the framework. At the end, I mentioned several alternative Python HTTP servers which use asynchronous I/O with an event-loop-based scheduler to handle parallelism and do work with multiprocessing.

In the second post, we looked at how asynchronous I/O works in general, and specifically how it works in Python–specifically how callback code can be rewritten in terms of functions with the async and await keywords, inspired by monadic I/O in functional programming languages.

Introduction

When talking about software maintainability, we always imply that you can extend or change a given software (even by another person than the original maintainer) without breaking the code or introducing bugs. This premise assumes that there is a good test suite making sure that your software still works as intended after the change (or with a new version of an external dependency). For example, the complexity of the software in the BIOfid software framework, both in the backend and the frontend, can only be tamed by applying tests that make sure that the code works as intended - now and in the future.

Introduction

Since 2004, the Bielefeld Academic Search Engine (BASE) offers an aggregated metadata search over scientific publications. By indexing well over 300 million records (60% of which are open access¹) from almost 10,000 international repositories, it provides researchers with an invaluable access to publications. In addition to offering a VuFind based discovery system, the aggregated data is also available via both a live search API and an OAI-PMH interface to enable re-use by 3rd party services.² As a general search engine for scientific documents, the indexed publications are not restricted to any academic discipline or field of research. And while BASE retains available subject terms and – to some extent – even tries to automatically assign Dewey Decimal Classification to a subset, it’s not always straight forward to find resources that pertain to a specific field. That’s where 3rd party services can come into play and try to cater to the needs of specific areas of research. To provide such a service, however, a method of selecting a subject specific subset is required.³

Why you may want to have authenticated users

There are a few features of web applications we – as users – grew accustomed to. Like bookmarking things on our favourite marketplaces for instance. For a Specialised Information Service, this feature is especially appealing, since it fits the workflow of a good number of scientists and humanists. You – as a researcher – can search a catalogue and bookmark anything that strikes your interest for further review. You can also export them into your reference system of choice.