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

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.
>

I don't find this compelling, because it assumes that the release
methodology of SQLite is fixed in stone.  If the SQLite developers were
asked to have a feature-fixed version of SQLite, fixing security problems
and only making backwards-compatible language changes as a web API needs, in
order to allow SQLite to be used as the major database component for web
applications, I'd be surprised if it wasn't at least given serious
consideration.

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.
>

With the massive scale of SQLite's use, I at least have no concerns of it
becoming a stale, unmaintained project in the foreseeable future, and I'd be
even less concerned if it became the foundation of a major web storage API.


> 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.
>

If SQLite was to be used as a web standard, I'd hope that it wouldn't show
up in a spec as simply "do what SQLite does", but as a complete spec of
SQLite's behavior.  Browser vendors could then, if their lawyers insisted,
implement their own compatible implementation, just as they do with other
web APIs.  I'd expect large portions of SQLite's test suite to be adaptable
as a major starting point for spec tests, too.

Creating such a spec would be a formidable task, of course.

-- 
Glenn Maynard