Am 9. Juli erschien Version 2.18 vom alternativen, nur Text Client Radegast. Im November 2014 verkündete sein Entwickler Latif Khalifa noch, keine Zeit mehr für seine Opensourceprojekte zu haben.
Radegast 2.18 wird dabei als kleines Update bezeichnet.
Die moderne Entwicklung von Software hat es so an sich, dass die Programmierer oft das Rad nicht mehr neu erfinden müssen, sondern sich bereits existierender Programmbibliotheken für alle möglichen Bereiche, wie beispielsweise Verschlüsselung, dem Abspielen von MP3s, Videos u.v.m. bedienen können. Der Entwickler nutzt die Schnittstellen der entsprechenden Bibliothek und baut sie in sein Produkt ein, fertig. Natürlich muss er damit auch ab und an sein Projekt der Bibliothek anpassen, wenn sich diese ändern sollte.
Das hier, werte Leser, ist Konqueror. Der Mehrzahl von euch wird Konqueror nichts sagen, es handelt sich dabei um den alten Dateimanager des Desktop Environments KDE unter *nix. Konqueror war schon immer fähig, als Webbrowser zu fungieren und hatte dazu eine eigene, kleine Websiterenderingengine namens KHTML eingebaut plus eine Javascriptengine namens KJS. KHTML war recht flott, leichtgewichtig und einfach in eigene Programme einzubauen.
KHTML kennt heute kaum noch einer, es wird auch nicht mehr weiter entwickelt. Als Apple im Jahre 2003 seinen eigenen Webbrowser namens Safari vorstellte, ging ein Raunen durch die Webszene. Denn in dieser Email meldete sich ein gewisser Don Melton bei den KDE-Entwicklern und verkündete der erstaunten Welt in der Mailingliste, dass Apples neuer Webbrowser auf einem Fork von KHTML mit KJS basieren würde. Dieser Fork, also eine auf Grundlage von KHTML unabhängige Weiterentwicklung trug damals den Namen WebCore, das Gesamtprojekt hörte auf den Namen Webkit.
Die KDE-Leute waren verzückt und gleichzeitig die Macher bei Mozilla verärgert, dass Apple nicht deren ebenfalls quelloffene Engine Gecko benutzt hatte. Gecko war den Entwicklern bei Apple zu groß, zu schwer einzubauen und zu langsam, aber KHTML genau richtig. Dafür konnte Gecko aber auch deutlich mehr Webseiten korrekt anzeigen, als dies bei KHTML der Fall war.
Webkit wuchs und gedieh und findet sich heute auf jedem Smartphone und Rechner als Engine, es ist die Basis für Safari und war die Basis für Google Chrome. An der Entwicklung von Webkit sind unter der Federführung Apples viele, bekannte Firmen beteiligt. Google verabschiedete sich allerdings 2013 von Webkit und gründete seinen eigenen Fork namens Blink. Der Grund dürfte einfach sein, dass man sich so aus der technischen Abhängigkeit von Apple befreien wollte. Ebenso verwendet bis heute der Second Life Viewer Webkit als Viewerkomponente.
Mozilla arbeitet übrigens selber schon seit längerem an einer vollkommen neuen Renderingengine namens Servo, die in einer dafür eigens geschaffenen Programmiersprache namens Rust implementiert wird. Man darf gespannt sein, was dabei am Ende herauskommen wird.
Das moderne World Wide Web hat ein Problem, nämlich sein Übertragungsprotokoll namens Hypertext Transfer Protokoll. Dieses ist recht einfach und designmäßig in die Jahre gekommen, das merkt man eben.
Es gibt bisher zwei Versionen davon, nämlich HTTP/1.0 aus dem Jahre 1996. Bei HTTP/1.0 wird für jede übertragene Datei oder Bild eine neue Netzwerkverbindung aufgebaut, die Daten übertragen und danach die Verbindung wieder geschlossen. Wenn man nur wenig überträgt, dann ist das kein großes Ding, aber eine moderne Webseite besteht heute locker aus über 80 verschiedenen Dateien oder mehr. Jede Verbindung, die per TCP/IP aufgebaut werden muss, benötigt einen gewissen Vorlauf im Betriebssystem als auch im Netzwerk und danach wird sie wieder geschlossen. Das ist so sinnvoll, als würde man für drei Kästen Bier im Supermarkt jeden Kasten Bier einzeln holen.
1999 kam dann eine Verbesserung namens HTTP/1.1 heraus, die bis heute der aktuell gültige Standard ist. Bei HTTP/1.1 kann man eine bereits bestehende Verbindung offen halten und darüber mehrere Dateien anfordern. Man spricht von persistenten Verbindungen und Pipelining, d.h. der Übertragung mehrerer Dateien über die offene Verbindung hintereinander. Das Problem daran ist nur, dass korrektes Pipelining extrem schwer zu implementieren ist und daher nutzt es kaum jemand wirklich. In Google Chrome beispielsweise ist Pipelining implementiert, aber standardmäßig abgeschaltet. Zudem gab es Benchmarks mit mehreren Webbrowsern und dabei keine wirklich meßbaren Unterschiede zwischen an- und abgeschaltetem Pipelining.
Ob nun HTTP/1.0 oder HTTP/1.1, beide Protokolle sind recht einfach gestrickt, sie genügen nicht mehr den heutigen Anforderungen im Webserverbereich wirklich und ein Flaschenhals. Die Übertragung von Webseiten könnte deutlich schneller sein, was aber wegen des zugrundeliegenden Übertragungsprotokolls bisher nicht möglich ist. Es ist ein Hemmschuh.
Google hat das Problem vor knapp zwei Jahren mit der Entwicklung des hauseigenen SPDY-Protokolls angegangen; dieses bildet nun die Grundlage für die aktuelle Entwicklung von HTTP/2.0, dessen Einführung in nächster Zeit absehbar sein wird.
Bei HTTP/2.0 wird zu jedem Webserver grundsätzlich nur noch eine TCP/IP-Verbindung aufgebaut und diese wird on the fly komprimiert. Die Übertragung findet binär statt und der Webserver beherrscht dabei das Multiplexing von verschiedenen Dateien gleichzeitig; auch erkennt er, welche Dateien der Webbrowser als nächstes höchstwahrscheinlich für den Seitenaufbau benötigt und schickt diese dem Browser von sich aus direkt zu.
HTTP/2.0 dürfte dem Web einen dringend benötigten, ordentlichen Geschwindigkeitsschub bringen, der die Breitbandleitungen deutlich besser als bisher auslasten wird.
Second Life bekommt aktuell Unterstützung für CDNs, also Content Delivery Networks, eingebaut. Aktuell gibt es einen Projektviewer dazu und rund 28 Regionen auf dem Mainland, die das unterstützen.
Das Problem daran ist nur: viele können sich unter einem CDN absolut nichts vorstellen, aber sie benutzen es täglich. Was also ist ein CDN und warum ist es gut?
Ein CDN ist, wie der Name schon sagt, ein Netzwerk, das Inhalte verteilt. Nehmen wir mal an, ín meiner Gegend gibt es zwei ALDI-Filialen, die eine ist drei Kilometer von mir entfernt und die andere zehn. Nehmen wir weiter an, ich als ökonomisch handelnder Mensch kaufe immer dasselbe Toilettenpapier bei ALDI, das es in jeder Filiale als Eigenmarke vorrätig gibt. Wohin werde ich natürlich fahren? Richtig: zu der Filiale, die näher an meinem Wohnort ist, denn das Angebot in dem Fall ist ja in allen ALDI-Filialen gleich und es gibt für mich absolut keinen vernünftigen Grund, in die weiter entfernte Filiale zu fahren.
Und genau das ist das Prinzip eines CDNs, nämlich die Inhalte eines Diensteanbieters geographisch (!) gesehen wirklich so nahe als möglich an den Abrufer zu bringen. Das geschieht dabei völlig automatisch, transparent und der Benutzer kriegt davon nichts mit. Der CDN-Anbieter muss dafür eine globale Infrastruktur betreiben.
Wie funktioniert das? Nun, in Second Life wird es für Meshes und Texturen freigeschaltet werden. Bekannte Anbieter von CDNs sind beispielsweise Akamai oder Amazon. Wenn ich also in Zukunft als Deutscher eine Textur runter laden will, dann geht diese Anfrage auf CDN-aktiven Regionen nicht mehr direkt an die Rechenzentren von Linden Lab in den USA, sondern an einen Server des CDN-Anbieters, der irgendwo in Europa steht. Der prüft dann zunächst, ob diese Textur schon lokal vorhanden ist, und wenn ja, dann schickt er mir diese direkt, was in einer deutlich besseren Ladezeit resultiert (das ist einfacher Physik und der Übertragungsgeschwindigkeit geschuldet, sprich man hat eine bessere Pingzeit). Wenn die Textur bisher nicht vorhanden ist, dann fordert er diese beim Stammserver an und hält sie danach für weitere Deutsche für eine gewisse Zeit vor.
Das ist alles. Dadurch haben wir dann in Zukunft eine Entkoppelung des Ladens von Texturen und Meshes von der Infrastruktur Linden Labs in den USA, weil das hauptsächlich über das CDN passieren wird. Als Ergebnis wird man eine spürbare Beschleunigung der Ladezeit von oft bzw. oft wiederholt besuchten Sims feststellen können. Wie hoch, das wird sich zeigen .
Zu beachten dabei ist allerdings, dass nach wie vor die Regionserver in den USA stehen und damit die Avatarpositionsberechnung, Physik usw. ausschließlich über dort geschehen wird.
Philip Rosedale arbeitet unter Hochdruck mit seinen motivierten und fähigen Mitarbeitern an der nächsten Inkarnation einer virtuellen Welt, High Fidelity. Linden Lab überraschenderweise auch schon seit längerem, auch wenn das Kind noch keinen offiziellen Namen hat – manche nennen es einfach Second Life The Next Generation (SL-TNG) – so soll doch bereits 2015 eine Beta verfügbar sein.
Beiden ist gemeinsam, dass sie ordentlich Manpower und ordentlich Geld zur Verfügung haben, um ihre Pläne Wirklichkeit werden zu lassen, dazu kommt noch sehr viel praktische Erfahrung mit dem Betrieb von virtuellen Welten. Während High Fidelity Opensource ist mit einigen, zentralen Diensten, wird SL TNG erst einmal Closed Source sein.
Aber denken wir mal ein wenig weiter und tun so, als ob zumindest einer dieser neuen Dienste verfügbar wäre: neue Möglichkeiten, zeitgemäßere Architektur, bessere Leistung und Geschwindigkeit.
Was wird dann aus Opensimulator? Bis auf einige Hartgesottene bin ich mir sicher, dass es vor allem wegen High Fidelity dann sehr rasch und stark an Bedeutung verlieren wird und irgendwann wohl sanft sterben wird, denn mit dem Erscheinen eines dieser Produkte wird es ziemlich sicher seine besten Zeiten schlagartig hinter sich haben.