Summary

  • Der W3C-Entwurf von 2009 beschrieb eine Browser-API für lokale Datenbanken mit einer SQL-Variante. Er hielt bereits fest, dass alle interessierten Implementierer SQLite verwendeten und dass der Verweis auf dessen Dialekt keine eigenständige Sprachbeschreibung ersetzte.
  • Am 1. November 2010 beschloss die Web Applications Working Group, Web SQL Database als Working Group Note statt auf dem Weg zur Recommendation zu veröffentlichen. Die Note vom 18. November dokumentierte die fehlenden unabhängigen Implementierungen; 2011 nannte W3C IndexedDB als Nachfolger der aufgegebenen SQL-Arbeit.

Zwei Produkte können denselben Fehler teilen und deshalb dieselbe Antwort geben. Bei Web SQL ging es noch grundlegender um die Definition der richtigen Antwort. Zwei Browser führten Anfragen über denselben SQLite-Kern aus. Gleiches Verhalten sagte dann etwas über diesen gemeinsamen Kern. Es sagte wenig darüber, ob eine andere Datenbank die Regeln allein anhand der Spezifikation verstehen konnte.

Der W3C-Arbeitsentwurf vom Dezember 2009 beschrieb eine asynchrone Schnittstelle: Datenbank öffnen, SQL-Anweisungen in einer Transaktion ausführen, Ergebniszeilen lesen. Beim Ablauf war der Text genau. Die durchgereichte Sprache hieß dagegen nur eine Variante von SQL. Der Entwurf benannte seinen eigenen Stillstand: Alle interessierten Entwickler hatten SQLite als Backend gewählt; den SQL-Dialekt einfach mit einem Verweis auf SQLite festzulegen, reichte für einen Standard nicht. Der Herausgeber suchte ausdrücklich jemanden, der ein unabhängiges Backend bauen wollte.

Das war keine Abrechnung mit SQLite als Software. Der Mozilla-Ingenieur Vladimir Vukicevic schrieb in einem Beitrag an die öffentliche W3C-Liste im April 2009, er möge SQLite und habe seine Aufnahme in Gecko befürwortet. Seine Sorge betraf Websites, die sich an dessen Eigenheiten bei Typen und Syntax gewöhnen würden. Eine für diese Eigenheiten gebaute Anwendung könnte an einem anderen Motor scheitern. Die Formel „mach es wie SQLite“ würde Browserhersteller zugleich an künftige Änderungen und Sicherheitswartung dieser Bibliothek binden. Das war seine technische Stellungnahme, keine Statistik über bereits gescheiterte Websites.

Für Website-Entwickler war die Falle angenehm unsichtbar. Eine Abfrage funktionierte in zwei Browsern; also schien sie portabel. Sie konnte aber auf einem Verhalten beruhen, das nur im gemeinsamen SQLite-Code festlag. Ein dritter Anbieter müsste dann entweder das Verhalten nachahmen oder inkompatible Seiten hinnehmen. Der Arbeitsgruppe fehlten eine abgegrenzte SQL-Sprache und Tests, mit denen sich eine unabhängig geschriebene Implementierung beurteilen ließ.

Die Sitzungsniederschrift vom 1. November 2010 hält zwei Implementierungen, wenig Antrieb zur Weiterarbeit, das gemeinsame SQLite-Backend und das Fehlen einer separaten Beschreibung des SQL-Teils fest. Die Gruppe einigte sich auf eine Working Group Note. Eine Wiederaufnahme bei neuem Interesse blieb im Gespräch; dafür hätte aber auch das Verfahren zu geistigen Eigentumsrechten neu begonnen werden müssen. Eine Note bewahrte das Papier, ohne es zur abgeschlossenen Empfehlung zu erklären.

Die Note vom 18. November erklärte den Stillstand offiziell mit dem Bedarf an mehreren unabhängigen Implementierungen. In Abschnitt 5 verlangte sie weiterhin den SQL-Dialekt von SQLite 3.6.19. Die Versionsnummer einer Bibliothek stand damit dort, wo ein eigenständig umsetzbares Sprachversprechen stehen sollte. W3C arbeitete an Web Storage und IndexedDB weiter. Im Überblick vom August 2011 beschrieb es die SQL-Datenbankarbeit als zugunsten von IndexedDB aufgegeben.

Die Quellen beziffern weder die später betroffenen Websites noch das genaue Ende der API in einzelnen Browsern. Dafür bräuchte es datierte Bestandsaufnahmen von Anwendungen und Versionen. Der dokumentierte Befund reicht dennoch weit: Zwei Verpackungen mit demselben Motor beweisen noch keine unabhängig implementierbare Sprache.

Originalquellen