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

On Mon, Nov 9, 2009 at 12:58 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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.

Indeed, I think that makes a big difference. It's also been shown that
the standard C library can be implemented by multiple different
implementations, the same can not be said for the SQLite SQL dialect.

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

I have very intentionally not pushed back heavily on the Web SQL DB
until I felt that we had an alternative solution to promote. So I do
have a different solution to promote, which is SimpleDB.

Further, I think the "multiple independent implementations" rule is
there exactly for the reason that I've been concerned about, to ensure
that the spec is reasonably implementable by several different
parties. You have yourself raised very similar concerns that the
theora spec might for patent reasons only be implementable by a single
library. So I don't think it's lawyering to point out that we're
potentially breaking that rule here.

I also very intentionally said "Ultimately I don't care much either
way really" in order to show that I wasn't going to block progress
based on this rule.

Ultimately what matters is that all UAs that want to can implement the
API. It might be ok to rely on a specific library if we were
reasonably certain that all vendors were ok with embedding that
library. But I don't think we are. I'm personally not ok with
embedding SQLite 3.6.19 (or versions with a compatible SQL dialect)
forever into Gecko. At some point I'm certain that we will want to
upgrade the SQLite implementation we use internally, and at that point
we'd have to ship two implementations. And at some point that version
SQLite 3.6.19 (and versions with compatible SQL dialect) of SQLite
will become unsupported, at which point it becomes our responsibility
to fix these bugs in a timely manner.

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

My impression is that there's two choices:

Either spec something that is so close to the SQLite dialect that it
effectively requires embedding a specific version SQLite to implement
the spec.
Or spec something that is unlikely to be compatible enough with SQLite
that it doesn't require a full SQL parser and optimizer.

Neither of this is particularly desired.

>> * 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 don't believe there *is* a good solution to the SQL dialect problem.
So I don't see what's disingenuous for me to cite this as a reason not
to implement.

However given that even if there was I would still prefer the SimpleDB
approach, for the other reasons mentioned, I don't think this
particular topic is going to lead anywhere.

Like I said, I would prefer to "park" the spec as a note, but I'm not
going to stand in the way if others want to bring it to Rec.

/ Jonas

Received on Friday, 13 November 2009 06:39:49 UTC