Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?

On Fri, Apr 1, 2011 at 9:39 AM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> 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.)

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.

For "normal" software this is fine. You simply retest your software
after upgrading to the latest version and if it treats any of your
queries differently, you simply adjust your query or your code to
account for this.

However web apps are afforded no such luxury. They have no control
over when users upgrade their browsers to one with a new version of
SQLite. This is why it is critically important on the web to maintain
stable APIs. Unfortunately SQLite does not provide such a stable API.

To make matters worse, since we are exposing the SQLite engine
directly to potentially harmful web content, it is extra important to
be tracking the latest version of SQLite as to pick up any and all
security fixes.

Second, as a browser developer, I am not at all excited about the idea
of locking myself in to shipping SQLite forever. What if a new better
embeddable SQL engine comes along and I want to switch to using that?
Just because SQLite is popular now doesn't mean that in 10 years it
couldn't be a unmaintained project largely replaced by some other
embeddable SQL engine.

Lastly, some vendors have expressed unwillingness to embed SQLite for
legal reasons. Embedding other peoples code definitely exposes you to
risk of copyright and patent lawsuits. While I can't say that I fully
agree with this reasoning, I'm also not the one that would be on the
receiving end of a lawsuit. Nor am I a lawyer and so ultimately will
have to defer to people that know better. In the end it doesn't really
matter as if a browser won't embed SQLite then it doesn't matter why,
the end result is that the same SQL dialect won't be available cross
browser which is bad for the web.

There are good reasons for the "two independent implementations"
requirement. We're not just following it as a goal in and of itself.

/ Jonas

Received on Friday, 1 April 2011 18:40:57 UTC