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.
No opinion on your other points; this is far from my area of expertise. -Boris
