- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Fri, 1 Apr 2011 12:39:22 -0400
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Glenn Maynard <glenn@zewt.org>, Benjamin Poulain <benjamin.poulain@nokia.com>, ext Nathan Kitchen <w3c@nathankitchen.com>, public-webapps@w3.org
On Thu, Mar 31, 2011 at 12:28 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > No, it actually sounds like a success; it prevented a "specification" being > created which would have been tied to a particular implementation, no matter > how "widely-deployed". > > For comparison, IE6 was very widely deployed circa 2002. And yet specifying > CSS, say, by saying "just do exactly what IE6 does" would not have been a > good idea. Neither is defining WebSQL to do exactly what some particular > version of SQLite does, and no one stepped up to define it better. IE6 is closed-source software written for a single platform. SQLite is in the public domain, works for all major operating systems and lots of minor ones, and is already used (I think?) by every major browser except IE. That makes all the difference. There's some benefit to having multiple interoperable implementations even if the reference implementation is public-domain, but enormously less than when the only implementations are controlled by particular parties. I think SQLite isn't a great long-term solution, because in the long term a single implementation stifles innovation. But it's also very powerful, pretty familiar to web developers (who are used to MySQL), requires vastly less implementation effort than making up a new system, and is in practice going to be much more interoperable than anything written separately by different browsers. So refusing to consider it just because there isn't a written standard or multiple interoperable implementations is not sound. When the Wikimedia Foundation was considering an official Board-approved policy for what file formats they'd allow for upload on sites like Wikimedia, the draft <http://meta.wikimedia.org/wiki/File_format_policy> required that the format be "Defined by an open standard, implementation, or specification not under proprietary control". Notice that an open *standard* was not required -- an open *implementation* was enough. .doc need not apply, but LaTeX or MediaWiki wikitext are perfectly fine. The proposal was never formally adopted, but I think this philosophy makes a lot of sense. Many (although certainly not all) of the reasons for standards evaporate when you have a reference implementation under a BSD-style license or better. So if the only objection to WebSQL is "there's no way we're going to get a formal spec or two interoperable implementations", I'd really encourage objectors to step back and ask themselves why they *want* a formal spec and two interoperable implementations. Those requirements are not axiomatic, they're means to obtain practical ends like allowing competitions and avoiding user lock-in. How many of those ends are really contrary to using SQLite as a de facto standard, and do the remaining ones really outweigh the practical advantages? (I came to this discussion very late, so apologies if there are additional objections to WebSQL that no one's mentioned in this specific thread, but have mentioned in the dozens of threads about this before now.)
Received on Friday, 1 April 2011 16:40:15 UTC