- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Mon, 4 Apr 2011 18:55:40 -0400
- To: Jonas Sicking <jonas@sicking.cc>, Joran Greef <joran@ronomon.com>
- Cc: public-webapps@w3.org
On Fri, Apr 1, 2011 at 2:39 PM, Jonas Sicking <jonas@sicking.cc> wrote: > There are several reasons why we don't want to rely exclusively on > SQLite, other than solely W3C formalia. > > First of all, what should we do once the SQLite team releases a new > version which has some modifications in its SQL dialect? We generally > always need to embed the latest version of the library since it > contains critical bug fixes, however SQLite makes no guarantees that > it will always support exactly the same SQL statements. . . . These are good reasons, and I have no problem with them. SQLite is designed with very different compatibility and security needs than the web platform has, and its performance goals might be different in some respects as well. There are various ways that you could address this short of making up something completely different, but I'm not sure whether it would be a good idea. Anyway, I didn't intend to reignite this whole discussion. The decision has been made, now we get to see what comes of it. On Mon, Apr 4, 2011 at 11:07 AM, Joran Greef <joran@ronomon.com> wrote: > SQLite has a fantastic track record of maintaining backwards compatibility. SQLite does not face anything close to the compatibility requirements that web browsers face. There are perhaps billions of independent web pages, which don't have any control over what browser versions they're being run in. These pages are expected to work in all browsers even if they were written ten years ago and no one has looked at them since, and even if they were written incompetently. Just because something has an excellent compatibility track record by the standards of application libraries doesn't mean it's compatible enough for the web.
Received on Monday, 4 April 2011 22:56:33 UTC