Summary

  • Le projet Web SQL de 2009 proposait une interface de bases locales interrogées par une variante de SQL. Il signalait déjà que les implémentations intéressées employaient toutes SQLite et qu’une référence à ce moteur ne définissait pas assez le langage.
  • Le 1er novembre 2010, le groupe Web Applications du W3C a décidé de publier Web SQL Database comme note de groupe, hors du parcours vers une recommandation. La note du 18 novembre constatait l’impasse ; en 2011, le W3C décrivait le travail sur la base SQL comme abandonné au profit d’IndexedDB.

Deux navigateurs peuvent donner la même réponse à une requête et ne constituer qu’un seul essai. Si chacun délègue SQL à SQLite, l’accord entre leurs résultats teste surtout le moteur qu’ils ont en commun. Pour savoir si un troisième navigateur peut participer, il faut une règle écrite assez précise pour être appliquée sans copier ce moteur. C’est cette pièce qui manquait à Web SQL.

Le projet de travail du W3C de décembre 2009 décrivait une interface asynchrone : ouvrir une base, lancer une commande dans une transaction, lire des lignes. La partie JavaScript avait des contours nets. La langue des requêtes, elle, n’était qu’une « variante de SQL ». Le projet disait explicitement que tous les implémenteurs intéressés utilisaient SQLite, et qu’une définition réduite à « faites comme SQLite » ne convenait pas à une norme. Il appelait un développeur prêt à réaliser un moteur indépendant.

Un message de Vladimir Vukicevic, ingénieur Mozilla, adressé à la liste du W3C en avril 2009, expose le problème sans faire de SQLite un coupable. Il se disait partisan de son intégration à Gecko. Mais SQLite avait ses propres choix de syntaxe et de types de données. Une application écrite pour ces choix pouvait mal fonctionner avec un autre moteur. Exposer ce comportement aux pages web ferait aussi porter aux éditeurs de navigateurs la maintenance et les problèmes de sécurité d’une bibliothèque particulière. C’était l’argument d’un participant à la discussion, pas un recensement des applications en panne.

Le piège pour un site était plus discret. Une requête pouvait fonctionner dans les deux navigateurs disponibles et sembler portable. Elle suivait pourtant les habitudes du même moteur, pas une spécification que chacun avait reproduite séparément. Pour un nouvel éditeur, choisir un autre moteur impliquait de deviner le comportement de SQLite ou de renoncer à la compatibilité. La normalisation avait besoin d’un dialecte borné, puis de tests capables de vérifier un moteur construit à partir de cette définition.

Le compte rendu de la réunion du 1er novembre 2010 est remarquablement direct. Deux implémentations existaient, mais le groupe ne voyait pas de volonté de faire avancer le texte. Elles utilisaient SQLite et aucun sous-ensemble autonome de SQL n’était spécifié. Le groupe a accepté de republier le document comme note. Des participants ont laissé ouverte une reprise en cas d’intérêt nouveau ; l’un a rappelé qu’un retour sur le parcours de recommandation imposerait de reprendre la procédure de propriété intellectuelle. Garder un texte consultable ne lui donnait pas le statut d’une norme achevée.

La note du 18 novembre 2010 inscrit l’arrêt dans son en-tête. Elle dit qu’il faut plusieurs implémentations indépendantes pour avancer. Plus loin, sa section sur SQL demande encore aux agents utilisateurs d’implémenter le dialecte de SQLite 3.6.19. Le moteur et même sa version servaient de définition pratique. Pendant ce temps, le W3C poursuivait Web Storage et IndexedDB. Dans son état des lieux d’août 2011, il décrivait l’approche SQL comme abandonnée au profit d’IndexedDB.

Ce verdict portait sur le travail de normalisation, pas sur un interrupteur qui aurait effacé Web SQL de tous les navigateurs. Les documents ne comptent pas les applications dépendantes. Ils montrent en revanche ce que deux produits ne suffisaient pas à prouver : qu’un langage du Web pouvait être implémenté indépendamment du moteur qui l’avait fait naître.

Documents originaux