W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: Web Storage & SQL

From: Kris Zyp <kris@sitepen.com>
Date: Thu, 09 Apr 2009 14:34:51 -0600
Message-ID: <49DE5BEB.1010002@sitepen.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: Boris Zbarsky <bzbarsky@mit.edu>, Giovanni Campagna <scampa.giovanni@gmail.com>, public-webapps@w3c.org
Hash: SHA1
Maciej Stachowiak wrote:
> On Apr 9, 2009, at 8:19 AM, Boris Zbarsky wrote:
>> Giovanni Campagna wrote:
>>> So why not adding a parameter on openDatabase() to specify what kind
>>> of database we want (and what kind of query language we will use)?
>>> I mean something like
>>> openDatabase(name, version, type, displayName, estimatedSize)
>>> where type can be any string
>>> so, for example, type = "sql" uses the standard SQL, type="sqlite"
>>> uses SQLite extensions, type="-vendor-xyz" is a vendor specific
>>> extension, etc.
>> How does this solve the original "no such thing as standard SQL,
>> really" issue?
> I agree that "no such thing as standard SQL" (or rather the fact
> that implementations all have extensions and divergences from the
> spec) is a problem. But I am not sure inventing a brand new query
> language and database model as proposed by Vlad is a good solution
> to this problem. A few thoughts off the cuff in no particular order:
> 1) Applications are starting to be deployed which use the SQL-based
> storage API, such as the mobile version of GMail. So it may be too
> late for us to remove SQL storage from WebKit entirely. If we want
> this content to interoperate with non-WebKit-based user agents, then
> we will ultimately need a clear spec for the SQL dialect to use,
> even if we also added an OODB or a relational database using some
> other query language.
> 2) It's true that the server side code for many Web sites uses an
> object-relational mapping layer. However, so far as I know, very few
> use an actual OODB. Relational databases are dominant in the market
> and OODBs are a rarely used niche product. Thus, I question Vlad's
> suggestion than a client-side OODB would sufficiently meet the needs
> of authors. Rather, we should make sure that the platform supports
> adding an object-relational mapping on top of SQL storage.
First, OODB's seem to be on the rise, albiet under different titles
lately (AppEngine, SimpleDB, CouchDB, Persevere). Second, when using
relational DBs, most devs use ORMs to interact with the DB, so they
are primarily working in the object-realm, even on the server. For
situations where data is transferred to the client (in data form),
devs stay in the object realm for the data transfer (JSON) and on the
browser in JavaScript. I don't see why we would want to force data
translation back to the relational realm in the last leg on the
browser when we have worked so hard to stay within object paradigm.

> 3) It's not obvious to me that designing and clearly specifying a
> brand new query language would be easier than specifying a dialect
> of SQL. Note that this may require implementations to actually parse
> queries themselves and possibly change them, to ensure that the
> accepted syntax and semantics conform to the dialect. We are ok with
> this.
I agree that we shouldn't be specifying a brand new query language. I
thought the idea was looking at existing query languages that would be
better fits for the web/JS environment. Nothing new would need to be
invented here.
> 4) It's not obvious to me that writing a spec for a query language
> with (afaik) a single implementation, such as jLINQ, is easier than
> writing a clear and correct spec for "what SQLite does" or some
> subset thereof.
JSONPath/JSONQuery seems like a far more mature path if an alternative
to SQL is to be considered, and has a pretty good set of
implementations (probably at least 5 different impls).

> Thus, I think the best path forward is to spec a particular SQL dialect,
> even though that task may be boring and unpleasant and not as fun as
> inventing a new kind of database.

In view of point #1, this may be the best course, I don't know, but I
mainly wanted to correct some of the statements above.

- --
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Received on Thursday, 9 April 2009 20:36:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC