W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: What do we mean by "parking" Web Database? [Was: Re: TPAC report day 2]

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 8 Nov 2009 23:12:22 -0800
Message-ID: <63df84f0911082312i4b459f53j55254bf16171e85c@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Arthur Barstow <art.barstow@nokia.com>, Charles McCathieNevile <chaals@opera.com>, public-webapps <public-webapps@w3.org>
>>> -Regards, Art Barstow
>>>
>>> [1] http://www.w3.org/2009/11/02-webapps-minutes.html#item12
>>> [2]
>>> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0477.html
>>
>>> From a technical point of view, are we expecting that there will
>>
>> actually be multiple independent interoperable implementations? If
>> Operas implementations uses SQLite in the backend, it seems like all
>> implementations are SQLite based and thus technically not independent.
>
> It should be noted that many aspects of the spec must be implemented
> independently even if SQLite is the underlying storage back end.

Indeed. I still personally wouldn't call it multiple independent
implementations though.

>> The reason I bring this aspect up is that this was one of the big
>> reasons that we didn't want to implement this at mozilla, that it
>> seemed to lock us in to a specific backend-library, and likely a
>> specific version of that library.
>
> We actually have a bit of a chicken-and-egg problem here. Hixie has said
> before he's willing to fully spec the SQL dialect used by Web Database. But
> since Mozilla categorically refuses to implement the spec (apparently
> regardless of whether the SQL dialect is specified), he doesn't want to put
> in the work since it would be a comparatively poor use of time. If Mozilla's
> refusal to implement is only conditional, then perhaps that could change.

I intentionally said "one of" above :)

There's several other reasons. I am not experienced enough to
articulate all of the reasons well enough, but here are a few:

* If we do specify a specific SQL dialect, that leaves us having to
implement it. It's very unlikely that the dialect would be compatible
with SQLite (especially given that SQLite uses a fairly unusual SQL
dialect with regards to datatypes) which likely leaves us implementing
our own SQL engine.
* SQL doesn't give any performance guarantees. Many times people tweak
their SQL in order to get the implementation to use a desired
evaluation stategy. This won't work in the likely event that different
implementations use different evaluation strategies for the same
query.
* The feedback we received from developer indicated that a SQL based
solution wasn't beneficial over a lower level API.

> In light of this divergent feedback, would Mozilla consider the SQL-based
> Web Database as a future implementation possibility in addition to SimpleDB,
> if the SQL dialect were to be fully specified?

So far I see no indication that we'd be interested in implementing a
SQL based solution even if the dialect was specified.

> I think the likely outcome of the current situation will be that new mobile
> browsers will have a harder time establishing themselves in the market,
> since many popular mobile web apps will be using a database technology where
> the query language is not fully specified. That would be an unfortunate
> outcome.

I definitely agree that we don't want a solution that punishes the
mobile market. I think the way to do that is to ensure that SimpleDB
is useful even for mobile platforms.

/ Jonas
Received on Monday, 9 November 2009 07:13:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:35 GMT