Jakoblog — Das Weblog von Jakob Voß

Wer Cloud sagt muss auch Bullshit sagen

In den letzten beiden Tagen fand in Göttingen ein GBV-Workshop zur Entwicklung der Lokalsysteme statt. Lokale Bibliothekssyteme (LBS, wobei im GBV dabei das LBS der Firma OCLC/PICA gemeint ist) oder Library Management Systems (LMS) sind für die zentralen Geschäftsgänge einer Bibliothek verantwortlich, d.h. für Ausleihe, Erwerbung, Nutzerverwaltung etc.

Von üblichen LMS wird die Recherche-Funktion zunehmend in so genannten Discovery Interfaces abgekoppelt. Idealerweise sollten auch andere Funktionen entkoppelt werden (z.B. die Benutzerverwaltung als LMS-unabhängiges Identity-Management). In der Realität sind die einzelnen Module von unterschiedlichen Herstellern aber nicht frei kombinierbar, womit deren ganzes Gerede von Schnittstellen und Services Augenwischerei ist.

Eine weitere Form der Verdummung von Bibliotheken ist mir auf der Veranstaltung mit mit dem Begriff Cloud aufgefallen. Cloud-Computing ist ein Buzzword, das anscheinend vor allem zur Verschleierung verwendet wird. Wenn wie im Workshop davon die Rede ist, dass „Daten in der Cloud verschwinden“, „eine eigene Cloud geschaffen werden soll“ oder gar Forderungen nach einer „Deutschland-Cloud“ laut werden, sollte eher von Nebel als von Wolke gesprochen werden. Denn ohne Angabe, was genaue für Dienste in eine Cloud ausgelagert werden sollen, ist der Begriff praktisch bedeutungslos und kann z.B. durch „Computer“, „Netzwerke“, „Server“ oder „Hosting“ ersetzt werden.

Dabei gibt es im Cloud-Computing eine etablierte Unterscheidung von drei groben Arten von Diensten: Bei Infrastruktur as a Service (IaaS) geht es um virtuelle Server. IaaS ist nicht mehr und nicht weniger als eine Alternative dazu, sich physische Rechner in die eigenen Räume zu stellen. Ein Beispiel für einen IaaS-Anbieter ist Amazon mit seinem Dienst Elastic Cloud Computing (EC2). Bei Platform as a Service (PaaS) wird eine Umgebung für eigene Programme bereitgestellt. PaaS ist nicht mehr und nicht weniger als eine Alternative zum Selber-Installieren und -Konfigurieren von Webservern, Programmiersprachen und allgemeinen Standard-Programmkomponenten. Die verschiedenen PaaS-Anbieter wie zum Beispiel Heroku, dotCloud und OpenShift unterscheiden sich vor allem darin, welche Programmiersprachen unterstützt werden.

Während verschiedene Anbieter von IaaS bzw. von PaaS jeweils in etwa vergleichbar sind, sieht es bei der dritten Art von Cloud anderes aus: Software as a Service (SaaS) bedeutet dass eine bestimmte Software nicht selber installiert und aktualisiert, sondern von einem Anbieter als Black-Box bereitgestellt wird. Ein populäres Beispiel für SaaS ist Google Docs. Während man bei IaaS und PaaS die Anbieter ähnliches bieten und man zwischen ihnen wechseln kann, hängt bei SaaS der Funktionsumfang völlig vom Anbieter ab und ein Wechsel ist praktisch nicht möglich. Im Gegenzug muss man sich als Nutzer keine Gedanken darum machen, wo die Software installiert ist und wie Updates durchgeführt werden. Beide Fragen wurden aber komischerweise auf dem GBV-Workshop diskutiert.

Vereinfacht gesagt lassen sich die drei Cloud-Arten so darstellen: Mit IaaS gibt es keine einzelnen Rechner mehr, mit PaaS gibt es keine einzelnen Installationsumgebungen mehr und mit SaaS gibt es keine einzelnen Updates mehr. Vor allem der letzte Punkt ist nach meinem Eindruck vielen nicht klar: bei SaaS gibt es keine Versionen oder Updates sondern nur neue Funktionen die im laufenden Betrieb aktiviert werden. Dieser Luxus wird erkauft mit (neben Geld) einer Einschränkung des Funktionsumfangs und mit einer Abhängkeit vom Anbieter.

So wie ich die Teilnehmer des GBV-Workshops verstanden habe, wollen Bibliotheken gerne die Vorteile aller Arten von Clouds zusammen: keine lästige Installation, Wartung und Auszeiten von Hard- und Software, kein Verzicht auf bisherige Funktionen („alte Zöpfe“) und alles am Besten so, dass Anbieter gewechselt werden können. Wer Bibliotheken so etwas verkaufen möchte, hat aber entweder keine Ahnung oder er begeht mutwillige Täuschung. Software ist immer entweder Arbeit in Form von selber zu erbringender Programmierung und Konfiguration, oder sie ist in ihrem Funktionsumfang auf einen kleinsten gemeinsamen Nenner beschränkt. Ich ziehe dabei die erste Variante vor, zumal Programmierung ja auch über Einstellungen, Skripte und Plugins möglich ist. Es bleibt aber eigene Programmierung – wer als Anwender davor zurückschreckt, muss sich mit Einschränkungen Abhängigkeiten und Auszeiten abfinden, sei es im Bibliothekswesen oder anderswo.

HTTP Content negotiation and format selection

In University of Southampton’s WebTeam Blog Christopher Gutteridge just complained that HTTP content negotiation could do better. And he is right. In a nutshell, content negotiation allows to retrieve different forms, versions or representations of a digital document at the same URI.

Content negotiation is an important part of the Web architecture, but sucks for several reasons. The main problem is: there is no consensus about what defines a format/version/representation etc. and how to refer to selected forms of a digital document. At least for selection by different versions in time, there is a good specification with Memento and Accept-Datetime header. Content negotiation by language (Accept-Language) is similar unless you want to query by other aspects of language (slang, readability…), because language tags are clearly defined and precise. But the concept of „content types“ (Accept header, also known as MIME types) is rather fuzzy.

Earlier I wrote about the difficulties to define „publication types“ – it’s the same problem: there is no disjoint set of content types, document types, publication types, or formats! Each document and each representation can belong to multiple types and types may overlap. The easiest case, described by Christopher, is a subset relation between two types: for instance every XML document is also a Unicode string (be warned: there is no hierarchy of types, but maybe a Directed Acyclic Graph!). Not even this simple relationship between content types can be handled by HTTP content negotiation.

Anyway, the real reason for writing this post is yet another CPAN module I wrote: Plack::App::unAPI implements unAPI. unAPI is a kind of „poor man’s content negotiation“. Instead of sending additional HTTP headers, you directly select a format with format=... parameters. In contrast to HTTP Content negotiation, an unAPI server also returns a list of all formats it supports. This is a strong argument for unAPI in my opinion. I also added a method to combine unAPI with HTTP content negotiation.

BibSonomy usability disaster

In addition to other citation management systems, I use BibSonomy. It’s one of the less known social cataloging tools. Not as commercial and shiny as Mendeley, but useful, especially if you happen to collect many papers in computer sciences. The BibSonomy team is open and friendly and the project is connected to the local University in Kassel (by the way, they are hiring students!). I still like BibSonomy – that’s why I wrote this rant.

Since last week BibSonomy has a new layout. Sure people always complain when you change their used interface, but this change is a usability desaster – at least if you work on a netbook with small screen, like me. To illustrate the problems here is a screenshot with my quick notes in red:

The screen is crowded with irritating and ugly user interface elements. The actual usage area is put into a little frame. Yes, a frame, in 2012! You cannot just scroll down to get rid of the header, because the frame is fixed. There are more flaws, for instance the duplication of account elements, scattered at not less than four places (logged in as…, logout, user:…, myBibsobomy) and the ugly custom icons (there are several great icon sets that could be used instead, for instance Silk, GCons, Glyphicons, Picol…). It does not get better of you try to edit content. I am sorry, but this is a usability disaster.

P.S: The BibSonomy team has responded and they fixed part of the problem with a nasty hack, based on actual screen size.