Summary

  • O rascunho Web SQL do W3C em 2009 descrevia uma API de banco de dados local consultado por uma variante de SQL. Ele já apontava que todos os implementadores interessados usavam SQLite e que uma referência ao motor não definia, por si, um dialeto portável.
  • Em 1º de novembro de 2010, o grupo Web Applications decidiu retirar o documento da trilha de Recomendação e publicá-lo como nota de grupo. A nota saiu no dia 18; em 2011 o W3C descreveu o trabalho com SQL local como abandonado em favor de IndexedDB.

Dois navegadores podem parecer dois experimentos e ainda compartilhar a peça que determina a resposta. Se ambos entregam uma consulta SQL ao SQLite, o mesmo resultado mostra a regularidade desse motor. Para transformar o resultado em padrão da web, faltava a pergunta mais difícil: outro implementador conseguiria escrever um mecanismo distinto usando só as regras publicadas?

O rascunho do W3C de dezembro de 2009 desenhava uma API assíncrona para abrir uma base, executar instruções numa transação e ler linhas. A interface tinha detalhes. A linguagem de consulta era uma “variante de SQL” cujo limite não estava descrito de forma independente. O próprio texto registrava o impasse: os interessados haviam escolhido SQLite; usar SQLite como definição do dialeto não bastava para uma norma. O editor convidava alguém disposto a construir outro backend para permitir a descrição da linguagem.

Em abril daquele ano, Vladimir Vukicevic, engenheiro da Mozilla, escreveu à lista pública do W3C. Ele disse gostar do SQLite e ter defendido sua entrada no Gecko. Sua crítica era a dependência criada quando páginas passassem a escrever consultas segundo as escolhas específicas desse motor, inclusive seus tipos de dados. Uma aplicação feita assim poderia não funcionar em outro banco. Mandar os fabricantes “fazerem como o SQLite” também lhes transferiria a manutenção e os riscos de segurança da biblioteca. Era um argumento técnico de um participante, não um levantamento de falhas ocorridas.

O desenvolvedor de um site podia facilmente confundir os sinais. Uma instrução que rodava nos dois navegadores disponíveis parecia interoperável. Mas os dois podiam simplesmente compartilhar a mesma interpretação não escrita de SQL. Um terceiro fabricante teria de imitar o comportamento do SQLite ou aceitar que o site falhasse. Faltavam um dialeto delimitado em palavras próprias e um teste que distinguisse conformidade de parentesco entre códigos.

A ata da reunião do W3C de 1º de novembro de 2010 registra duas implementações, pouca disposição para avançar, o mesmo SQLite por baixo e nenhuma especificação separada para o subconjunto de SQL. O grupo concordou em republicar o texto como nota. Havia a possibilidade de voltar ao processo de Recomendação se surgisse interesse, mas alguém observou que o procedimento de propriedade intelectual teria de recomeçar. Manter a discussão publicada não equivalia a endossá-la como padrão concluído.

A nota de 18 de novembro de 2010 anunciou o fim do trabalho naquela trilha por falta de implementações independentes. Na seção de SQL, ainda mandava os agentes de usuário implementar o dialeto de SQLite 3.6.19. Um número de versão de biblioteca ocupava o lugar de uma definição autônoma. O W3C continuou a desenvolver Web Storage e IndexedDB; seu panorama de agosto de 2011 chamou o trabalho com SQL no navegador de abandonado em favor do último.

Esses documentos não datam a retirada de Web SQL de cada navegador nem contam quantos sites o usavam. Um inventário de versões e aplicações daria essa medida. O que eles comprovam é outra falha: duas vitrines com o mesmo mecanismo atrás não servem como dois testes independentes da linguagem.

Fontes originais