Beschränkt und doch gefährlich
Ob und wie stark das storageChange-Objekt in seiner Wirkung eingeschränkt wird, wird noch diskutiert. So können derzeit nur Skripte mit derselben Funktion sowie von derselben Domain und Port aus das Objekt verwenden. Diese engen Grenzen lassen Probleme mit beliebten Skripten oder einem Wechsel zwischen HTTP- und HTTPS-Verbindungen gar nicht erst aufkommen.
Auch wenn sich die neuen Möglichkeiten für Webentwickler wie ein Traum anhören mögen, könnten sie schnell zum Albtraum werden: Dann nämlich, wenn zwei Fenster auf dieselben Dateien zugreifen und einen Wettlauf darum starten, wer die Daten als erstes korrumpiert (kritischer Wettlauf). Experten streiten deshalb darüber, um das Objekt um einen "Mutex"-Algorithmus (mutual exclusion), der dieses schädliche Ansinnen auf beiden Seiten - Server wie Client - einschränkt, ergänzt werden müsse.
Einer der jüngsten Entwürfe der HTML5-Spezifikation sieht einen Mutex eher als potenzielle Geschwindigkeitsbremse und gibt die Empfehlung ab, mögliche Datenbeschädigungen unter diesen Umständen zuzulassen. Weiter heißt es: "Alternativen, die ohne ein Skript-Lock auf Client-Seite auskommen, werden dringend gesucht."
Derartige Alternativen sind auch notwendig, könnte es andernfalls doch zu bizarren Auswüchsen kommen, wenn mehrere Browserfenster gleichzeitig geöffnet sind. Dann liefen zwar verschiedene Instanzen eines Codes parallel, jeder Prozess hätte aber nur Zugriff auf einem einzigen unveränderlichen lokalen Datenbestand.
In der Spezifikation heißt es: "Verschiedene Website-Betreiber, die sich einen Host teilen - beispielsweise mehrere Blogger auf Wordpress.com (Anm. d. Red.) - teilen sich ein localStorage-Objekt. Es gibt kein Feature, den Objektzugriff pfadabhängig zu beschränken." Wieviel Speicherplatz bekommt also jeder einzelne? Lässt sich DNS-Spoofing verhindern? localStorage beantwortet zwar viele Fragen, wirft aber mindestens genauso viele neue auf.
SQL-Datenbank und IndexedDB
Die Schlüssel-Wert-Paare im localStorage-Objekt sind in der Regel mächtig genug, um viele Grundfunktionen auszuführen - sie sind jedoch keineswegs mit relationalen Datenbanken vergleichbar, die Daten in indexierten Tabellen speichern. Für diese Anforderung bietet der HTML5-Standard zwei neue Optionen.
Die erste ist der Standard Web SQL Database, der bereits vor längerer Zeit entworfen und implementiert worden ist, bevor er zugunsten einer abstrakteren Variante etwas aus dem Blickfeld geriet. WebKit- und Opera-Anwender können mit der in dem Standard beschriebenen abgespeckten Datenbank-Engie SQLite Tabellen erstellen und Wertereihen speichern - SQL-Grundwissen vorausgesetzt. Weil das W3C aber entschied, Web SQL Database nicht weiterzuentwickeln, ist der Standard heute nur noch für experimentierfreudige Tekkies geeignet - er wird trotz allem weiterhin von vielen Browsern unterstützt.
An seine Stelle trat die Indexed Database - sie ist vollkommen SQL-frei und enthält massenweise Schlüssel-Wert-Paare, analog zum localStorage-Objekt. Der Unterschied: Dank ihres Indexes lassen sich benötigte Daten schneller finden. Browser speichern jede Tabelle in einem B-Baum, um die Ergebnisrecherche zu beschleunigen und den Programmieren die Möglichkeit einzuräumen, die eingegebenen Daten zu sortieren. Der indexierte Speicher schließt kritische Wettläufe, die im localStorage noch möglich sind, dadurch aus, dass er alle Änderungen im Code als Transaktionen ausführt. Datenbankadministratoren mögen das gut finden, ausreichende Praxiserfahrungen mit IndexedDB liegen jedoch noch nicht vor. So enthält die aktuelle Version des HTML5-Entwurfs die Anmerkung, dass noch entschieden werden müssen, was geschehe, wenn eine dynamische Transaktionen ein Datenbankobjekt sperren wolle - das betroffene Objekt aber bereits von einer anderen Transaktion gesperrt sei. Also noch viel zu tun…
Lesen Sie auf der folgenden Seite alles über neue Möglichkeiten zum Offline-Browsen und potenzielle Eingriffe in die lokale Festplatte…