- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 10 Apr 2009 13:53:04 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: public-webapps@w3c.org
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. Regards, Maciej
Received on Friday, 10 April 2009 20:54:14 UTC