Re: What do we mean by "parking" Web Database? [Was: Re: TPAC report day 2]

On Tue, Nov 10, 2009 at 12:44 AM, Maciej Stachowiak <mjs@apple.com> wrote:

> If that were the extent of the implementation, I might agree. However, that
> doesn't accurately characterize at least WebKit's WebDatabase
> implementation. WebKit has around 15k lines of code which implement
> asynchronicity, do checking and rewrites on the queries, export DOM APIs,
> manage transactions, expose result sets, etc. It's true that SQLite has a
> fair bit more code. But then again, the image decoding library we use has
> more code than our <img> element implementation.
>

OK, but those image formats do have their own specs.

I think it's worth specifying and testing the layers above the query
> language even if, for whatever reason, the query language does not get
> specified.
>

That may indeed be valuable, and yet unsatisfactory for the open Web
platform.

I think it would be unhealthy if <img> only supported one format and that
format wasn't specified anywhere.

On Nov 9, 2009, at 3:12 AM, Robert O'Callahan wrote:
>
> You're right that precedent is weak here, but I think database APIs aspire
> to work with larger data sets than the DOM does, so big-O guarantees are
> more important.
>
>
> Is SimpleDB going to give big-O performance guarantees? (The current draft
> does not appear to.)
>

I don't know, but providing them seems an easier task than specifying a SQL
query optimizer. That would be important even if the first iteration of the
spec doesn't provide such guarantees.

At the Web Apps WG face-to-face meeting at TPAC, all parties agreed (in the
> room at least) to let the spec continue without fully specifying the SQL
> dialect. The reason is that all parties who currently have or are in the
> process of developing implementations did not appear to need it,
>

Implementations may not need it if they import the right version of SQLite,
but the Web still needs it.

and the parties that would be blocked (Mozilla, Microsoft) said their
> decision would not be swayed by having a spec, and would not implement
> regardless. Thus, it did not seem there would be a practical benefit to
> specifying the SQL dialect. Thus, those present said they were satisfied to
> specify that SQLite v3 is the dialect.
>

What exactly does that mean? Is it a specific version of SQLite? Almost
every SQLite release, even point releases, adds features.

The fact that SQLite bundles new features, bug fixes and performance
improvements together into almost every release makes it especially
difficult to build a consistent Web API on. Have you frozen your SQLite
import to a particular version? Or do you limit the SQLite dialect by
parsing and validating queries? Or do you allow the dialect to change
regularly as you update your SQLite import?

I thought there was a consensus that pointing to a pile of C code isn't a
good way to set standards for the Web. That's why we write specs, and
require independent implementations so we're not even accidentally relying
on a specific pile of C code. This seems to be a departure from that.

We already ship SQLite and implementing Web Database using SQLite would
> definitely be the path of least resistance for us. We're just concerned it
> might not be the right thing for the Web.
>
>
> My thoughts on this are as follows:
>
> 1) It seems that a database layer that's less "opinionated" than SQL is a
> better target for library authors; by having less conceptual baggage and
> policy, it makes it easier for different conceptual models (such as object
> oriented stores) to be layered on top. Thus, library developers are likely
> to want a lower-level solution.
>
> 2) It seems that a database layer with a good amount of high-level concepts
> (including some kind of query language) is likely to be easier to code
> against directly for many use cases. Thus, application programmers,
> particularly in environments where extra abstraction layers are particularly
> costly
>
> 3) Some mobile web developers have existing investment in SQL in
> particular, and do not appear to have had problems with it as a model. It
> would be a shame to abandon them, as in many ways they have been better
> pioneers of offline Web apps than mainline desktop-focused Web developers.
>
>
> It seems plausible to me that SQL is not the best solution for all storage
> use cases. But it seems like a pretty aggressive position to say that, as a
> result, it should be out of the Web platform (and not just augmented by
> other facilities). It seems like that would underserve other use cases
>

Some of your message seems to have been lost in transmission...

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]