blog · git · desktop · images · contact


Orientierung: Gopher

2011-11-04

Ich mag es, wenn Dinge technisch und konzeptionell einfach sind. Deswegen verwende ich Arch Linux, mutt statt Thunderbird, Vim, manchmal ed und so weiter. „Aus Einfachheit erwächst Flexibilität und Übersichtlichkeit, aus Übersichtlichkeit erwächst Wartbarkeit“, heißt das Mantra. Im luftleeren Raum kann Einfachheit aber nicht existieren, sondern man braucht Bezugspunkte. Deswegen behaupte ich, dass man nicht mal eben einfache Software schreiben und einfache Architekturen bauen kann, sondern dass das ein fortwährender Prozess ist. Man muss sich stetig orientieren.

Das heutige Web ist etwas, das ich aus technischer Sicht nicht mehr als „einfach“ bezeichnen mag. Ein paar Dinge hat Meillo in zwei schönen Rants angesprochen. In etwa diese Richtung geht auch mein Empfinden. Folglich möchte ich nun im Hinblick auf das Web hier und da ein paar zusätzliche Orientierungspunkte anregen.

Seit kurzem gibt es da links im Menü der Webseite den Punkt Gopher. Ja, genau, gemeint ist das Gopher-Protokoll. Warum du, falls du darauf klickst, vielleicht nichts siehst, erzähle ich gleich. Wenn Gopher für dich ein Fremdwort ist, dann könnte das daran liegen, dass du zu spät geboren wurdest. Gopher kann man heute zwar zurecht als historisches Protokoll bezeichnen, da es nur noch von einer Hand voll Leuten eingesetzt wird. Dennoch bin ich der festen Überzeugung, dass sich – gerade heute – ein Blick darauf lohnt. Man sieht sehr schön, an welchen Stellen wir im Web falsch abgebogen sein könnten. Auf ein paar prägnante möchte ich eingehen.

Das Gopher-Protokoll ähnelt FTP in der Hinsicht, dass man bei Anfrage eines Verzeichnisses normalerweise ein sogenanntes „Menü“ vom Server als Antwort bekommt. Die Struktur (also der „Quellcode“) dieses Menüs ist – wie bei FTPs „NLST“, aber im Gegensatz zu den Directory Listings, die manche Webserver erzeugen – fest vorgegeben. Ein Menü listet in der Regel die Inhalte eines Verzeichnisses auf, es kann aber auch dynamisch generiert oder mit Annotationen versehen sein. Im Menü kann ich eine Datei auswählen oder ein Unterverzeichnis, Suchanfragen sind auch möglich. Ziele können sich auf dem aktuellen Server befinden, müssen es aber nicht. Insgesamt ist Gopher damit eine Art verteiltes Dateisystem. Es gab sogar früher Clients, die Gopher-Menüs wie im lokalen Dateisystem als Baumansicht dargestellt haben – leider darf ich die Screenshots dazu nicht verlinken.

So sieht beispielsweise das momentane Menü für meinen Server im lynx aus:

Screenshot

Die Menüs sind der springende Punkt bei Gopher und einer der beiden Hauptgründe, warum ich mich länger als fünf Minuten mit dem Protokoll beschäftigt habe. Insbesondere deshalb, weil sie eine andere Zusatztechnologie unnötig machen, ohne die das heutige Web kaum mehr existieren könnte: Feeds.

Was ist ein Feed? Ein Feed ist eine wohldefinierte Darstellung von Inhalten. Es ist festgelegt, dass es eine Reihe von „Items“ gibt, die wiederum bestimmte Eigenschaften besitzen können. Warum verwendet man Feeds, zum Beispiel bei einem Blog? Weil man interessierten Besuchern die Möglichkeit geben möchte, Änderungen am Inhalt des Blogs zu verfolgen, ohne die Webseite manuell besuchen zu müssen. Auch ist gewünscht, dass man sich dazu nicht wie bei einem Newsletter „registrieren“ muss. Das heißt, das Format eines Feeds muss gut maschinenlesbar und für alle Blogs einheitlich sein. In der Summe kann ich so meinen Feedreader mit verschiedenen Feeds befüllen und somit an einer zentralen Stelle sehr viele Quellen beobachten. Die Automatisierung ist dabei essentiell, denn manuell ist diese Aufgabe nur äußerst mühsam zu bewältigen. Ein Programm muss die Feeds für mich beobachten können.

Weshalb brauche ich Feeds? Weil jede Webseite anders aufgebaut ist. Ich kann einem hypothetischen „Webreader“ nicht einfach eine Reihe von Webseiten vorwerfen, die er beobachten soll. Es wäre für ihn zwar möglich, zu erkennen, wenn sich etwas auf der Seite ändert, aber es ist nur mit sehr viel Intelligenz und Komplexität möglich, annähernd zu bestimmen, was sich auf der beobachteten Seite geändert hat. Wurde nur ein Werbebanner getauscht? Hat sich nur die Struktur der Seite geändert, aber der Inhalt ist gleich geblieben? Kann ein Programm nur schwer entscheiden. Ein Feed behebt also diesen Mangel und bastelt nachträglich diese Einheitlichkeit wieder dazu.

Zurück zu Gopher und seinen Menüs. Diese sind einheitlich. Würde ich alle Blogposts über Gopher zur Verfügung stellen wollen, dann müsste ich sie im einfachsten Fall nur als einzelne Dateien in ein Verzeichnis werfen. Fertig. Jedes Blog wäre dann so aufgebaut. Natürlich ist das „langweilig“, aber ein Feed und all die dafür notwendige Komplexität wäre nicht mehr notwendig. Ganz so spartanisch muss es aber gar nicht sein, ein bisschen Aufbereitung ist schon möglich:

Screenshot

Dieses Prinzip ist natürlich nicht nur auf Blogs beschränkt. Ich denke nicht, dass es irgendjemand bemerkt hat, aber ich habe zum Beispiel lange Zeit einen Feed für meine Desktop-Screenshots gehabt. Das war ein separates Skript, zusätzlicher Code. Man hätte damit aber coole Dinge machen können, zum Beispiel hätte es ähnlich zu den Blog-Planeten Screenshot-Planeten geben können, welche die monatlichen Screenshot-Threads erweitern oder gar hätten ablösen können.

Jedes Gopher-Verzeichnis wird über ein gleichartiges Menü dargestellt, also kann ich jedes solche Verzeichnis ohne zusätzliche „Feed-Komplexität“ beobachten und die einzelnen Menüs wie heute die Feeds aggregieren. Ob da nun Blogposts drinliegen, Screenshots, Musik, Logfiles oder was auch immer – spielt keine Rolle. Und ich bekomme diese Funktionalität geschenkt, da sie dem Gopher-Protokoll inhärent ist.

Der andere Punkt ist, dass das Gopher-Protokoll trivial ist. Es gibt nur eine Art der Kommunikation: Anfrage, bestehend aus einer einzigen Zeile, und eine Antwort. Alles ist Plain Text ohne XML- oder HTML-Geraffel (aber, ja, ich darf auch HTML übertragen – beliebige Inhalte nämlich). Das ist alles derart einfach, dass man einen Gopher-Server in etwa 100 funktionalen Zeilen als Shellskript realisieren kann. Das habe ich hier gemacht und dabei gleichzeitig das ebenfalls sehr interessante xinetd genauer kennengelernt:

Repo von sgopherd

Ein Blick in die Beschreibung von sgopherd zeigt aber, dass das Ding trotzdem sehr viele Funktionen hat. Mir sind das, ehrlich gesagt, schon fast zu viele Funktionen. Vieles ließe sich auch anders lösen ohne all diese Intelligenz im Server. Trotzdem ist der Code so kurz. Ich möchte nicht wissen, wieviel Code notwendig ist, um alleine einen HTTP-1.0-Header korrekt zu verarbeiten.

Auf der Seite des Clients sieht es auch nicht komplizierter aus. Hier gophcatch, das Äquivalent eines Feedreaders für Gopher:

Repo von gophcatch

Es mag geschummelt aussehen, dass ich dort curl und lynx verwende. Aber schauen wir doch mal, an welchen Stellen: curl wird zum Abrufen eines Gopher-Menüs eingesetzt. Das hätte ich auch genauso gut mit netcat machen können, da curl auch nur das reine Menü zurückliefert ohne es zu interpretieren. curl hat aber schönere Optionen für Timeouts. lynx wird benutzt, um Auszüge neuer Items abzurufen – also beispielsweise die ersten paar Zeilen eines neuen Blogposts. Auch hier wäre genauso gut netcat möglich gewesen, doch lynx versteht HTML und kann das schön als Plain Text ausgeben. Beide Programme, curl und lynx, werden also zur Lösung von Problemen eingesetzt, die nicht durch das Gopher-Protokoll entstehen.

Ganz abgesehen davon, dass gophcatch auch nur ein simples Shellskript ist. Man vergleiche das in der Komplexität mit gängigen Feedreadern für’s Web.

Das waren die schönen Seiten an Gopher. Ich mag das Protokoll wirklich sehr, weil es derart einfach ist, aber auf der anderen Seite durch feste Strukturen wieder Funktionalität ermöglicht, die so im Web nur sehr umständlich zu realisieren sind.

Natürlich ist mir klar, dass Gopher tot ist und nicht mehr auf der Höhe der Zeit. Es gibt keine Verschlüsselung, keine Zugangsbeschränkung und vorallem keine ausführliche Angabe des Typs eines Inhalts. Auf gut Deutsch, Gopher kennt keine Mime-Types und kein Content-Encoding. Es gibt lediglich eine sehr rudimentäre Angabe des Typs innerhalb eines Gopher-Menüs – wenn ich aber „blind“ eine Datei anfordere, ohne vorher das Menü dazu gesehen zu haben, weiß ich nicht, was auf mich zukommt. Deswegen wird der Typ übrigens meistens direkt in der Gopher-URL notiert.

Außerdem gibt es fast keinen Support in den Clients mehr. lynx und curl können es noch, natürlich gibt es auch noch Mosaic, der auch heute noch läuft:

Screenshot

Aber das war’s dann im Prinzip auch schon. Für den Firefox und ein paar andere gibt es ein Addon:

Wer beispielsweise luakit verwendet, schaut in die Röhre. Generell ist der Client-Support nicht mehr so toll, wenn man von Overbite absieht.

Einen signifikanten Beitrag zum Untergang Gophers hat übrigens die University of Minnesota geleistet, die das Protokoll sogar ursprünglich entwickelt hat. Dann aber kamen sie irgendwann auf die glorreiche Idee, Nutzungsgebühren für ihre Serverimplementierung verlangen zu wollen. Das hat für ausreichend Unsicherheit gesorgt, denn wer garantierte, dass nicht auch das Protokoll selbst im nächsten Moment derart eingeschränkt werden würde? Gleichzeitig wurde das (freie) Web immer beliebter. Schon war’s geschehen.

Wie lange ich meinen Gopher-Server nun laufen lasse, weiß ich nicht. Er läuft ja nur zum Spaß. Ich will damit nicht die Welt verbessern und vielleicht schalte ich ihn nächste Woche auch wieder aus. Gopher ist auch keinesfalls die Lösung für alle Probleme. Es ist eben nur ein Protokoll, das zwar durch die Menüs dazu auffordert, die Inhalte sauber zu strukturieren, aber ein Zwang ist das nicht. Es gibt daher sogar Leute, die eine „normale“ Webseite mit PHP im Gopherspace laufen lassen.

Ich möchte aber dazu motivieren, auch bei heute so alltäglichen Dingen wie dem Web mal über den Tellerrand zu schauen. Insbesondere jüngere Menschen. Schaut euch hier und da mal an, was es schon gab und wie das damals funktioniert hat. Vergleicht es mit dem, was wir heute machen. Fragt euch, ob die Dinge zwangsläufig so funktionieren müssen, wie sie es im Moment tun – oder ob es nicht auch einfachere Wege gibt. Man muss durch Vereinfachungen nicht automatisch an Funktionalität verlieren. Nehmt euch auch unbedingt die Zeit, das Gopher-Protokoll an sich zu erkunden, da sich die Einfachheit erst dann wirklich erschließt, denn bei der reinen Benutzung fühlt sich das alles auch nicht so anders an als das Web.

Ganz abgesehen natürlich davon, dass so ein „gopher hole“ eine wohlige, nerdfreundlich Atmosphäre schafft. Wer sich dafür begeistern kann, mal einen Blick auf meinen Server zu werfen, dem sei insbesondere der Linkbereich empfohlen, um auch den Rest des noch existierenden Gopherspace erkunden zu können.

Plüsch!

– Nachtrag 2024-02-04: Der Gopher-Server ging nun wieder offline. Das Experiment hat seinen Zweck erfüllt.

Comments?