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

On Mon, Nov 9, 2009 at 9:58 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> On Nov 8, 2009, at 11:12 PM, Jonas Sicking wrote:
>
> 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.


Yes. Multiple implementations passing query strings (more or less) verbatim
to SQLite for parsing and interpretation would not pass that judgement call
... IMHO, but wouldn't you agree?


>  * 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.


I think the problem is rather coming up with a SQL definition that can be
implemented by anything other than SQLite (or from scratch, of course). One
weird thing about SQLite is that column types aren't enforced. So either the
spec requires something like SQLite's "type affinity" (in which case it
doesn't fit well with most other SQL implementations, and precludes common
performance optimizations), or it requires strict type checking (which
perhaps you could implement in SQLite by adding CHECK constraints?). But the
latter course is probably incompatible with deployed content, so contrary to
Jonas I expect the spec would be implementable *only* on top of SQLite (or
from scratch, of course), or perhaps some unnatural embedding into other
engines where all values are text or variants. Experience with alternative
implementations would be important.

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.
>

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.

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.


That doesn't seem logical to me. The spec work has to be done if Web
Database is to advance through the spec process. You want it to advance even
if Mozilla doesn't agree to implement it. Therefore, the spec work has to be
done. (And if there was a SQL dialect spec that's simple and elegant and
amenable to multiple implementations and compatible with your deployed
content, that would certainly be a large point in favour of Web Database.)

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).
>

Do you have easy access to knowledge about the sort of complex queries these
mobile apps do? That would be very useful.

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.

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]