Die lächerlichste Technologie der Welt

Eng zusammenhängend mit meinem letzten Beitrag zum Thema string-parsing, muss ich heute schon wieder einen rant von mir geben. Diesmal geht es (wie bereits im Titel stehend) um: Die lächerlichste Technologie der Welt...

...ist das WWW wie wir es heutzutage kennen. Besser noch: all die Dinge die sich Web2.0 schimpfen.

Es fängt eigentlich noch relativ harmlos an. Ein Stück Software erfasst eine Reihe von Eingabefeldern, wertet sie aus und erstellt daraus eine Internetadresse mit Parametern. Sie generiert also einen String wie "http://www.php-seite.com:80/search?q=foo%20bar&do=fuck%you".
Da dem Nutzer das natürlich bis hier her, verdammt wenig gebracht hat, werden die Teile dieser Adresse weiterverwendet (die positive Variante wäre dass die Teile noch vorhanden sind, aber realistisch ist wohl eher dass das selbe Stück Software intern den String an eine andere Funktion schickt und die diesen wieder parst).

Also wird (nach diversem Parsen, auflösen von Domainnamen und dem verpacken der Daten in Netzwerkpakete) wieder ein String vom Browser generiert und an einen anderen Rechner gesendet. Das sieht dann vlt so aus: GET /search?q=foo%20bar&do=fuck%you HTTP/1.0
Zusätzlich werden wohl noch einige weiteren Zeilen gesendet, in denen dann z.B. steht dass man von "http://www.php-seite.com/search" kommt und den Browser "I am a fucking stupid Browser (Version 0.01 pre pre Alpha)" verwendet, aber grundsätzlich reicht das auch erstmal für unsere Zwecke.

Mit also diesem Text konfrontiert, fängt wieder ein anderes Stück Software an zu rödeln und parst diesen String. Wer ist da? Was will er? Wie will er es? Was muss ich in welches Log schreiben? (OK, dafür fehlen momentan noch Daten.)
Also stellt es fest dass die datei "search" aus dem Wurzelverzeichniss geholt werden sollte. Nach einem kurzen Blick auf die Festplatte (*rödel*, gut dass es nicht im 10. Unterverzeichniss lag und erstmal für jedes Elternverzeichniss eine Datei namens .htaccess gesucht, gelesen und geparst werden musste), stellt er fest dass alles unter /search aber eigentlich auf /lib/search_function.php umgeleitet werden soll.

Weil aber search_function.php ein PHP-Script zu sein scheint, stellt unser zweites Stück Software fest dass es eigentlich nicht zuständig ist und reicht es an ein drittes weiter, dem es einfach diese Datei und die vollständigen Parameter der Anfrage zum Parsen in die Hand drückt.

Dieses dritte Ding, fängt also an die Adresse noch ein weiteres Mal zu zerlegen und bereitet ein paar hundert Variablen vor, mit denen in der Hand es dann mal anfängt zu interpretieren was in der Datei so rumliegt. In der Anfrage selbst, bemerkt es dann vlt. noch zusätzlich dass Softwarestück #1 bereits mehrere Anfragen in Folge gestartet hat und das wahrscheinlich alles irgendwie zusammengehört.

Bis hierher war der ganze Vorgang evtl. überkomplex, sinnlos und defekt, aber ab jetzt wird es wirklich übergeschnappt...

Unser Stück Software #3 liest also dass noch ein gutes Dutzend weiterer Dateien gebraucht werden, holt sich auch diese von der Festplatte, rechnet noch etwas rum, parst noch mehr Text und erstellt dann zu guter letzt einen neuen String. Der könnte dann vlt. so aussehen: "SELECT * FROM `foobar` WHERE `text` LIKE '%foo%' and `text` LIKE '%bar%' (Zugegeben, das ist evtl. etwas unfair, eine Suche würde vlt. eher über eine spezielle Volltextsuchengine laufen, aber es gibt ja genug andere Fälle)

Jetzt haben wir also wieder einen String und den reicht #3 an Codehaufen #4 weiter. Dieser (wie sollte es anders sein?) parst diesen String wieder, sucht im RAM und auf der Festplatte und wirft ein paar Daten in einen String den dann Nummer #3 wieder parsen darf.
Das Spiel wiederholen #3 und #4 vlt. noch ein paar dutzend (ich habe auch schon >>100 erlebt) mal und irgendwann fängt #3 dann an einen weiteren, wahrscheinlich erheblich komplexeren String zusammen zu bauen (z.B. irgendwas mit "

#2 sucht noch schnell in ein paar zusätzlichen Daten von #3, schreibt diese zusammen mit einer groben Übersicht über die ursprüngliche Anfrage auf die Festplatte (Log) und liefert den langen String zurück über das Netzwerk an #1.

Bereit für noch eine Steigerung dieses Irrsinns?

Natürlich fängt der Browser (#1) sofort an den Text zu zerlegen und danach ein komplexes Bild aufzubauen, das man doch mal anzeigen könnte. Zwischendurch werden immer mal wieder weitere, fehlende Daten bemerkt (steht ja im String) und von #2 abgeholt (hier kann man den ganzen Teil bis hierher noch 1-2x wiederholen, dazu noch einige dutzend Durchläufe mit weniger Umfang, z.b. weil #2 feststellt dass #3 nicht benötigt wird und nur eine Datei von der Festplatte liest und zurückgibt.).

Das dauert jetzt natürlich etwas, aber dennoch: irgendwann steht das Bild und auch eine Verwaltungsstruktur die die Daten des HTML-Dokumentes, diverser CSS-Daten und was weiß ich noch alles enthällt, liegt auch bereits im RAM.
Meistens werden während dieses Aufbaus, weitere Substrings dieser Dokumente durch einen Parser gejagt und mit Daten der Verwaltungsstruktur gefüttert. Nein, eigentlich sind es eher verschiedene Parser, für verschiedenste Arten von Daten.

Wir hätten da z.B. reine, statische Definitionen wie welcher Teil des Bildes aussehen soll (und hier fängt der Browser an wild nach den passenden Elementen im Baum zu suchen, diese umzugestallten, Kindelemente mit bestimmten Eigenschaften zu versehen, ... kurz: das Bild wird völlig umgebaut)
Andere Teile enthalten Befehle was der Browser jetzt schon wieder ganz tolles und interaktives tun soll. Animationen darstellen (mehrfach hintereinander das Bild ausgeben, umbauen und wieder ausgeben), Werte im Baum ändern (und natürlich das Bild entsprechend umbauen) oder auch einfach nur ein paar weitere Anfragen an den Server senden, er soll doch bitte noch weitere Inhalte von irgendwelchen Adressen liefern (und wieder Strings die zusammengestellt und abgesendet werden).
Gerne produzieren diese letzteren Inhalte auch weitere, die genau wie sie selbst aussehen, irgendwo mit der Verwaltungsstruktur verknüpft werden und zu anderen Zeitpunkten dann wieder vom Parser ausgeführt werden müssen.

Weil das natürlich alles noch viel zu langweilig wäre, gibt es natürlich noch jede Menge weitere Inhaltstypen, für die #1 Blöcke im Bild frei hält und die dort von wieder anderen Programmen dargestellt werden, die mit bereits an #1 angehängte Erweiterungen weitergeleitet werden (meistens auch wieder Strings oder Binärdaten die an interpretierte Sachen von der Festplatte des Rechners gegeben werden) oder auch ab und zu Sachen, die komplett von #1 unabhängige Programme auf dem Rechner starten.

Ich hab hier zwischendrin irgendwann den Überblick verloren, wann wie oft Daten als String übertragen wurden und wie oft welcher String umständlich geparst wurde, auch Festplatten und Zwischenspeicher werden weit mehr als genug belastet. Eines ist mir jedoch mehr als klar:
Dieser ganze Prozess ist völlig im Eimer! Die eigentliche Grundfunktion von HTTP ist nunmal Dateien aus einem entferntem Dateisystem abzurufen. HTML ist dann nur ein Dateityp, der ursprünglich mal Informationen in einem Textdokument übersichtlicher darstellen sollte, WIE die Darstellung erfolgt sollte dabei weitestgehend dem Browser überlassen bleiben.

Was das alles mit interaktiven Inhalten und Interaktionen mit anderen Clients über einen zentralen Server zu tun haben sollte, warum wir permanent ein Bild neu aufbauen, statt einfach Zeichenfunktionen bereitzustellen, warum wir HTML so verbiegen und erweitern bis wir pixelgenau Bilder damit auf jedem Bildschirm gleich anzeigen können, warum wir für jedes von hunderten Bildern auf der Seite eine neue Verbindung aufmachen, warum wir denken dass alle 1-5 minuten nachzufragen ob sich was geändert hat wäre eine gute Methode um aktuelle Daten zu haben, warum wir permanent von Programmen Texte parsen lassen die gerade Programme erstellt haben, warum wir "Sitzungen" über hunderte Verbindungsaufbauten und Dateiübertragungen hinweg zusammenzufassen versuchen...

...ja, alle das und noch viel mehr bleibt mir völlig unklar. Nein! Eigentlich ist das schon wieder gelogen, denn der Grund ist klar: das sind alles Altlasten und Produkte von Situationen in denen es einfacher war ein ungeeignetes Werkzeug anzupassen bis es gerade so funktioniert statt ein neues Werkzeug zu erfinden.
Die einzigen unbeantworteten Fragen sind eigentlich: "Warum scheint das außer mir keiner zu bemerken?" und "Wann sind wir endlich an dem Punkt, da unser permanent verbogenes Werkzeug endlich mal nicht mehr genug biegsam ist und endlich keine Wahl mehr bleibt als etwas sinnvolles zu bauen?"