On Nov 8, 2009, at 11:12 PM, Jonas Sicking wrote:
-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.
Would you call multiple implementations that use the standard C
library independent? Obviously there's a judgment call to be made
here. I realize that in this case a database implementation is a
pretty key piece of the problem. But I also think it would be more
fruitful for you to promote solutions you do like, than to try to find
lawyerly reasons to stop the advancement of specs you don't (when the
later have been implemented and shipped and likely will see more
implementations).
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.
The SQL dialect could, of course, be specified in a way that it could
work on top of SQLite with some reasonable filtering and preprocessing
steps. I don't see a reason to expect otherwise, and in particular
that it would be so different that it would require writing a new SQL
engine. So this reason seems to be based on an unwarranted assumption.
* 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.
Does SimpleDB give performance guarantees? Does any Web platform spec
give performance guarantees? Even DOM Core methods have different Big-
O complexity in Gecko and WebKit. So this doesn't seem very persuasive.
* The feedback we received from developer indicated that a SQL based
solution wasn't beneficial over a lower level API.
This is the only reason that seems particularly compelling. However,
as I said at TPAC, Apple has received very different feedback from
developers who have actually worked with that API. Does Mozilla
completely discount that feedback?
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.
So basically, at this point the spec for the SQL dialect is blocked on
Mozilla, since no one is interested in doing that spec work if it
won't actually lead to wider implementation. Thus, I think it's
somewhat disingenuous for Mozilla to cite lack of SQL spec as a reason
not to implement. If it were not for your refusal on other grounds,
then it's highly likely the SQL dialect spec would be produced.
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.
I don't think SimpleDB is useless for mobile platforms. You certainly
*could* use it. But it does have three significant downsides compared
to the SQL database: (1) it's very different from what developers have
already (happily) been using on mobile; (2) the target design point is
that it's primarily expected to be used through JavaScript libraries
layered on top, and not directly (so you have to ship more code over
the wire); and (3) for more complex queries, more of the work has to
be done in JavaScript instead of in the database engine (so
performance will likely be poor on low-power CPUs). For these reasons,
I expect a lot of mobile developers will stick with the SQL database,
even if we also provide something else.
If you have ideas for how to improve SimpeDB on these dimensions, I'd
be glad to hear it. But I'm not sure it's really possible to address
them without significantly changing the design direction of SimpleDB,
so I'm not really expecting they will be solved.
Regards,
Maciej
