- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sun, 8 Nov 2009 23:12:22 -0800
- 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 UTC