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

Re: Web Storage & SQL

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 10 Apr 2009 13:53:04 -0700
Cc: public-webapps@w3c.org
Message-id: <EF673912-B4BC-4ACF-9A9A-3D49EBD398D2@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

On Apr 9, 2009, at 5:38 PM, Boris Zbarsky wrote:

> Maciej Stachowiak wrote:
>> 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.
> That's fine; I'm not sure of that either.  I have no particular  
> opinion on that question, in fact.
>> 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.
> This is a price of early adoption, sure.
>> 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.
> That's true, but it's not a given that we want this content to  
> interoperate as-is.  Early adopters of known in-flux technologies  
> typically realize that they might have to make changes; if a  
> different data storage API is decided on, or if the subset of SQL  
> that's decided on doesn't match what these apps are using, then  
> they'll need to change.
> So while I agree that it might be difficult for Webkit to remove the  
> SQL support it shipped as soon as some other approach is decided on  
> (if that even happens), it doesn't follow that other UAs would need  
> to ship SQL support at that point.
> There are strong arguments for not breaking existing content, of  
> course, but there are also strong arguments for not having  
> experimental implementations of early drafts completely dictate the  
> standardization process.

I don't think this one point should be decisive by itself. But I don't  
think it should be given zero weight either. I do think the existence  
of an implementation of the current spec and Web content using it  
somewhat raises the burden of proof on anyone proposing a redesign.

Note that one of the clients in question is the offline-enabled mobile  
version of GMail. I think this demonstrates that the SQL-based  
Database Storage can serve the needs of an advanced and polished Web  
application. In addition, we have a rough demonstration that it is  
practically implementable in a modern Web engine.

One clear problem identified despite these examples is that we do not  
have a precise enough spec for the query language to make truly  
independent interoperable implementations possible. It seems to me  
that significantly redesigning database storage is not necessary to  
address this. "X is underspecified so let's do Y or Z instead" is not  
a very strong argument in my opinion. Another issue raised is that a  
different database model (OODB for instance) may work better for  
content authors. I would say we do not have very compelling evidence  
yet that such a design would be better, or that it could meet the  
various requirements, and we do not even have a concrete strawman  
proposal that we could start evaluating.

Received on Friday, 10 April 2009 20:54:14 UTC

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