Summary

  • W3C의 2009년 Web SQL 초안은 로컬 데이터베이스를 SQL 변형으로 질의하는 브라우저 API를 담았다. 하지만 관심 있는 구현자 모두가 SQLite를 사용했고, SQLite를 가리키는 것만으로는 독립적인 언어 규격을 만들 수 없다고 적었다.
  • W3C Web Applications 작업반은 2010년 11월 1일 이 문서를 권고안 경로에서 빼고 작업반 노트로 다시 내기로 했다. 18일 노트는 독립 구현 부족을 기록했고, W3C의 2011년 개관은 IndexedDB로 방향을 옮겼다고 설명했다.

표준화 회의에서 구현을 세는 일은 중요하다. 하지만 숫자 둘이 언제나 두 번의 검증을 뜻하지는 않는다. Web SQL을 지원하던 두 구현이 SQL 해석을 모두 SQLite에 맡겼다면, 일치하는 결과는 공유 엔진의 일관성을 보여준다. 다른 엔진이 문서만 보고 같은 결과를 낼 수 있는지는 여전히 모른다.

2009년 12월 W3C 작업 초안은 데이터베이스를 열고 트랜잭션에서 문을 실행해 결과 행을 읽는 비동기 API를 설명했다. 호출 구조는 구체적이었다. 하지만 안으로 넣는 SQL은 단지 변형이라고 불렸다. 초안은 관심 있는 모든 구현자가 SQLite를 후단에 놓았고, SQL 방언 설명이 SQLite 참조에 머물러 있어 표준으로는 부족하다고 인정했다. 편집자는 별도 후단을 구현할 사람을 공개적으로 찾았다.

SQLite 자체가 형편없다는 얘기가 아니었다. Mozilla 기술자 Vladimir Vukicevic는 2009년 4월 W3C 공개 메일에서 자신이 SQLite를 좋아하고 Gecko 도입을 주장했다고 밝혔다. 우려는 그 엔진의 자료형과 구문 선택이 웹 페이지에 노출되는 데 있었다. 그 선택에 맞춰 작성한 앱은 다른 데이터베이스에서 같은 방식으로 움직이지 않을 수 있다. 브라우저 제조사에 “SQLite처럼 하라”고 하면, 해당 코드의 변화와 보안 유지도 브라우저 플랫폼의 부담으로 들어온다. 이는 당시 토론 참여자의 기술적 주장이지 실제 장애 사이트 수의 측정치는 아니다.

사이트 개발자에게는 함정이 더 매끄럽다. 쿼리가 두 브라우저에서 실행되면 서로 다른 구현과 호환된다고 생각하기 쉽다. 그러나 공통점이 SQLite라면, 앱은 표준 문서가 아닌 한 엔진의 특성에 의존했을 수 있다. 세 번째 브라우저가 다른 엔진을 택하려면 문서화되지 않은 동작을 흉내 내거나 사이트와의 불일치를 감수해야 한다. 그래서 독립적인 SQL 범위와 그에 맞는 시험이 필요했다.

2010년 11월 1일 W3C 회의록은 구현 둘이 있지만 진전을 밀어붙일 뜻은 약하고, 두 구현 모두 SQLite 위에 있으며 별도의 SQL 부분집합도 정의하지 않았다고 적었다. 작업반은 Web SQL Database를 노트로 다시 내기로 합의했다. 관심이 돌아오면 재개할 수 있다는 발언과 함께, 권고안 경로에 다시 올리려면 지식재산 절차를 새로 시작해야 한다는 지적도 남겼다. 문서를 보존하는 것과 표준으로 승인하는 것은 달랐다.

2010년 11월 18일 노트는 여러 독립 구현이 필요해 작업을 중단했다고 밝혔다. 본문의 SQL 장은 여전히 사용자 에이전트가 SQLite 3.6.19의 방언을 구현해야 한다고 했다. 엔진의 버전 번호가 언어 경계의 자리를 차지한 셈이다. W3C는 Web Storage와 IndexedDB 작업을 계속했고, 2011년 8월 기술 개관은 SQL 기반 브라우저 데이터베이스 작업을 버리고 IndexedDB로 갔다고 정리했다.

이 기록은 이미 배포된 브라우저에서 Web SQL이 언제 제거됐는지, 얼마나 많은 앱이 의존했는지 알려주지 않는다. 그 결과를 알려면 버전별 브라우저와 당시 앱 목록이 필요하다. 표준화가 멈춘 이유는 분명하다. 한 엔진을 공유한 두 제품은 그 엔진과 독립된 언어의 존재를 증명하지 못했다.

원자료