TPAC report day 2

[Charles McCathieNevile-2]

Sorry folks, it was a long meeting for me so this was delayed.

The draft minutes are included at  
http://www.w3.org/2009/11/02-webapps-minutes.html starting from the WebIDL  
section - http://www.w3.org/2009/11/02-webapps-minutes.html#item06

We discussed

WebIDL
   We're going to update it to look like ECMAScript 5, and look for some  
tests of usng it in existing stuff like DOM 2 to show it works, but wait  
to push it to Rec, advising specs who rely on it that it is in fact  
considered stable and they should be able to go ahead with that dependency.

Selectors API
   Version 1 is ready for CR but needs a tiny bit of test suite polishing  
so we can get it finished. A separate email covers the missed item on  
SelectorsAPI v2 - http://www.w3.org/mid/4AF1DF02.3000303@... (we  
ran out of time)

DOM 3 Events
   Mostly a jint discussion with i18n on how to deal with the issue of how  
we represent what you get from Key events as data about the key

Offline storage / databases
   The SQL-based Web Database proposal will probably not be implemented by  
major players so is being shifted to a "parked and of historical interest"  
mode while we work on the Web Simple Database proposal from Nikunj. We  
also touched on Datacache, and ended with an action for Nikunj to explain  
how it relates to appcache if you have the two running together.

Second CORS
   A presentation from Maciej gave us an easier framework to work through  
the issues and questions in a more productive way, although we are still  
in discussion phase. There is further email on the list.

New Events
   We agreed to take on an extension to DOM 3 Events covering multi-touch,  
orientation, and similar, rather than having them all wait until DOM 4 or  
push back the DOM 3 Events spec futher.

Administrivia
   A quick joint discussion between the widgets and APIs parts of the group  
to say waht we are doing and thank everyone.

Special props to Jonas for scribing half a day, which is above and beyond  
the call of duty. Thanks to everyone else for turning up and helping us  
move forwards...

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Arthur Barstow]

On Nov 7, 2009, at 3:53 PM, ext Charles McCathieNevile wrote:

> The draft minutes are included at
> http://www.w3.org/2009/11/02-webapps-minutes.html starting from the  
> WebIDL

Thanks for the summaries Chaals!

> Offline storage / databases
>    The SQL-based Web Database proposal will probably not be  
> implemented by
> major players so is being shifted to a "parked and of historical  
> interest"
> mode while we work on the Web Simple Database proposal from Nikunj. We
> also touched on Datacache, and ended with an action for Nikunj to  
> explain
> how it relates to appcache if you have the two running together.

The minutes for the Web Database discussion [1] don't address what we  
mean by "parking" Web Database.

I heard Hixie say it should be included in a call for pre-LC comments  
thus I included it in the related call on 4 November [2] and members  
of the group have an opportunity to raise issues if they think Web  
Database is not ready for a LCWD.

However, later in the week, I participated in some hallway  
discussions where members of the group said they prefer Web Database  
be "parked" by publishing it as a Working Group Note (rather than a  
LCWD):

[[
http://www.w3.org/2005/10/Process-20051014/tr.html#q75

Working Group Note

A Working Group Note is published by a chartered Working Group to  
indicate that work has ended on a particular topic. A Working Group  
MAY publish a Working Group Note with or without its prior  
publication as a Working Draft.
]]

So, when we say we want to "park" Web Database, what do we mean:  
publish as LCWD, publish as Working Group note, something else? If  
necessary, we can start a CfC on this question.

-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

[Jonas Sicking-2]

On Sun, Nov 8, 2009 at 7:24 AM, Arthur Barstow <art.barstow@...> wrote:

> On Nov 7, 2009, at 3:53 PM, ext Charles McCathieNevile wrote:
>
>> The draft minutes are included at
>> http://www.w3.org/2009/11/02-webapps-minutes.html starting from the WebIDL
>
> Thanks for the summaries Chaals!
>
>> Offline storage / databases
>>   The SQL-based Web Database proposal will probably not be implemented by
>> major players so is being shifted to a "parked and of historical interest"
>> mode while we work on the Web Simple Database proposal from Nikunj. We
>> also touched on Datacache, and ended with an action for Nikunj to explain
>> how it relates to appcache if you have the two running together.
>
> The minutes for the Web Database discussion [1] don't address what we mean
> by "parking" Web Database.
>
> I heard Hixie say it should be included in a call for pre-LC comments thus I
> included it in the related call on 4 November [2] and members of the group
> have an opportunity to raise issues if they think Web Database is not ready
> for a LCWD.
>
> However, later in the week, I participated in some hallway discussions where
> members of the group said they prefer Web Database be "parked" by publishing
> it as a Working Group Note (rather than a LCWD):
>
> [[
> http://www.w3.org/2005/10/Process-20051014/tr.html#q75
>
> Working Group Note
>
> A Working Group Note is published by a chartered Working Group to indicate
> that work has ended on a particular topic. A Working Group MAY publish a
> Working Group Note with or without its prior publication as a Working Draft.
> ]]
>
> So, when we say we want to "park" Web Database, what do we mean: publish as
> LCWD, publish as Working Group note, something else? If necessary, we can
> start a CfC on this question.
>
> -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.

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.

Ultimately I don't care much either way really. Though it would be
nice to make it clear that it's not expected that the spec will be
implemented in all browsers.

/ Jonas

[Maciej Stachowiak]

On Nov 8, 2009, at 12:43 PM, Jonas Sicking wrote:

> On Sun, Nov 8, 2009 at 7:24 AM, Arthur Barstow  
> <art.barstow@...> wrote:
>> On Nov 7, 2009, at 3:53 PM, ext Charles McCathieNevile wrote:
>>
>>> The draft minutes are included at
>>> http://www.w3.org/2009/11/02-webapps-minutes.html starting from  
>>> the WebIDL
>>
>> Thanks for the summaries Chaals!
>>
>>> Offline storage / databases
>>>   The SQL-based Web Database proposal will probably not be  
>>> implemented by
>>> major players so is being shifted to a "parked and of historical  
>>> interest"
>>> mode while we work on the Web Simple Database proposal from  
>>> Nikunj. We
>>> also touched on Datacache, and ended with an action for Nikunj to  
>>> explain
>>> how it relates to appcache if you have the two running together.
>>
>> The minutes for the Web Database discussion [1] don't address what  
>> we mean
>> by "parking" Web Database.
>>
>> I heard Hixie say it should be included in a call for pre-LC  
>> comments thus I
>> included it in the related call on 4 November [2] and members of  
>> the group
>> have an opportunity to raise issues if they think Web Database is  
>> not ready
>> for a LCWD.
>>
>> However, later in the week, I participated in some hallway  
>> discussions where
>> members of the group said they prefer Web Database be "parked" by  
>> publishing
>> it as a Working Group Note (rather than a LCWD):
>>
>> [[
>> http://www.w3.org/2005/10/Process-20051014/tr.html#q75
>>
>> Working Group Note
>>
>> A Working Group Note is published by a chartered Working Group to  
>> indicate
>> that work has ended on a particular topic. A Working Group MAY  
>> publish a
>> Working Group Note with or without its prior publication as a  
>> Working Draft.
>> ]]
>>
>> So, when we say we want to "park" Web Database, what do we mean:  
>> publish as
>> LCWD, publish as Working Group note, something else? If necessary,  
>> we can
>> start a CfC on this question.

Representing one of the implementors of this spec, I'd prefer that we  
proceed to LCWD instead of publishing as a Note. With multiple  
implementations likely, it seems better to have the full W3C review  
process, and to have a test suite developed, etc. W3C has published  
many specifications that are supported by 0/5 browsers, so I don't  
think 3/5 support would be a reason to stop the standards process.

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

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

At the face-to-face, Mozilla representatives said that most if not all  
of the developers they spoke to said they wanted "anything but SQL" in  
a storage solution. This clashes with our experience at Apple, where  
we have been shipping Web Database for nearly two years now, and where  
we have seen a number of actual Web applications deployed using it  
(mostly targeting iPhone). Our developers, who actually used the SQL-
based solution rather than just considering what it might be like,  
were all very happy with it. We received various points of feedback  
about our solutions for offline Web Apps in general, but to my  
knowledge not one developer said SQL was a problem for them in practice.

It seems pretty clear to me that, even if we provide Web SimpleDB as  
an alternative, our mobile-focused developers will continue to use the  
SQL database. First, they will not see a compelling reason to change.  
Second, SimpleDB seems to require more code to perform even simple  
tasks (comparing the parallel examples in the two specs) and seems to  
be designed to require a JS library to be layered on top to work well.  
For our mobile developers, total code size is at a premium. They seem  
less willing than desktop-focused Web developers to ship large JS  
libraries, and have typically used mobile-specific JS libraries or  
aggressively pruned versions of full JS libraries.

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? Would  
Hixie consider specifying the SQL dialect if lack of spec turns out to  
be Mozilla's sole reason to refuse to implement?

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.

>
> Ultimately I don't care much either way really. Though it would be
> nice to make it clear that it's not expected that the spec will be
> implemented in all browsers.

I think it's up to browser implementors to make clear what their plans  
are, to the degree they choose to do so.

Regards,
Maciej

[Jonas Sicking-2]

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

[Maciej Stachowiak]

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

[Robert O'Callahan-3]

On Mon, Nov 9, 2009 at 9:58 PM, Maciej Stachowiak <mjs@...> 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]

[Maciej Stachowiak]

On Nov 9, 2009, at 3:12 AM, Robert O'Callahan wrote:

On Mon, Nov 9, 2009 at 9:58 PM, Maciej Stachowiak <mjs@...> 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 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.

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.

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

Indeed, it is a challenge to find the right design point. Right now it looks like no one is going to take up this challenge.

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.

Is SimpleDB going to give big-O performance guarantees? (The current draft does not appear to.)

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

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

Note: I would try to find Apple resources to help write a SQL dialect spec if anyone says it will materially help them to have such a spec (and the level of interest doesn't reach the threshold where Hixie wants to write it himself). I don't think I could get resources if it's just a busywork exercise.

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.

I don't have easy access to that knowledge, but I can attempt to inquire.

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

Regards,

Maciej

[Robin Berjon-2]

On Nov 9, 2009, at 09:58 , Maciej Stachowiak 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. I realize that in this case a database implementation is a  
> pretty key piece of the problem.

At the very least I would expect the CR-exit criteria to require two  
interoperable implementations of the specification made using  
different SQL back-ends. Otherwise this would be like implementing  
something in Gecko and counting Firefox, XulRunner, Seamonkey, etc. as  
independent implementations.

> 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 personally am not trying to be lawyery about this, but I think it's  
only fair to request that this specification be done at the level we  
expect from others. I therefore don't see much of a point in going to  
LC without the SQL dialect being specified — it's not a finished spec.

--
Robin Berjon - http://berjon.com/

[Anne van Kesteren-2]

On Mon, 09 Nov 2009 08:12:22 +0100, Jonas Sicking <jonas@...> wrote:
> * 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.

 From what I understood so far this would also be the case with the Web  
B-Tree Database proposal (maybe even more so given that all SQL  
implementations currently have the same underlying engine). Am I missing  
something?


--
Anne van Kesteren
http://annevankesteren.nl/

[Maciej Stachowiak]

On Nov 9, 2009, at 3:49 AM, Robin Berjon wrote:

> On Nov 9, 2009, at 09:58 , Maciej Stachowiak 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. I realize that in this case a database implementation is a  
>> pretty key piece of the problem.
>
> At the very least I would expect the CR-exit criteria to require two  
> interoperable implementations of the specification made using  
> different SQL back-ends. Otherwise this would be like implementing  
> something in Gecko and counting Firefox, XulRunner, Seamonkey, etc.  
> as independent implementations.

I agree that your Gecko example would be questionable. But to give an  
example on the other side of the fence, WebKit uses a copy of  
Mozilla's image decoding code, and yet I think our implementation of  
the <img> element clearly counts as independent. I would say choice of  
SQL back end falls somewhere between these two examples.

>
>> 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 personally am not trying to be lawyery about this, but I think  
> it's only fair to request that this specification be done at the  
> level we expect from others. I therefore don't see much of a point  
> in going to LC without the SQL dialect being specified — it's not a  
> finished spec.

Those present at the Web Apps WG face-to-face session on this topic  
generally agreed otherwise. Not to say that no one can disagree, but  
it seemed that most could live with a spec for only the API layers. I  
did not insist on a query language spec, because just advancing the  
API spec seemed like the most practical way to move forward at the time.

Regards,
Maciej

[Robert O'Callahan-3]

On Tue, Nov 10, 2009 at 12:44 AM, Maciej Stachowiak <mjs@...> 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]

[Robert O'Callahan-3]

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

I agree that your Gecko example would be questionable. But to give an example on the other side of the fence, WebKit uses a copy of Mozilla's image decoding code, and yet I think our implementation of the <img> element clearly counts as independent. I would say choice of SQL back end falls somewhere between these two examples.

I think it's very different from <img>. <img> implementations support multiple formats, Web Database implementations only support one dialect, with no way to switch between them. The widely used <img> formats are pretty well specified and have many independent implementations each, the Web Database dialect is not well specified and has only one implementation. It makes sense to view <img> as a portal to an unrestricted set of image formats, but it doesn't make sense to view Web Database as a generic API to various SQL dialects, IMHO.

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]

[Charles McCathieNevile-2]

On Mon, 09 Nov 2009 03:44:09 -0800, Maciej Stachowiak <mjs@...>  
wrote:

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

This is not at all the sense that I got. Hixie agreed to specify something  
that he could copy-and-paste, since he doesn't see the value in working  
hard on agreeing to a dialect where two major players aren't interested,  
and others are sufficiently unimpressed by the SQL approach that they plan  
to follow the WebSimpleDB approach.

> The reason is that all parties who currently have or are in the process  
> of developing implementations did not appear to need 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.

In other words, there is a specified dialogue - but not enough apparent  
energy to try and go further.

My sense is that this much agreement was considered important to justify  
keeping the spec in the WG.

> Note: I would try to find Apple resources to help write a SQL dialect  
> spec if anyone says it will materially help them to have such a spec  
> (and the level of interest doesn't reach the threshold where Hixie wants  
> to write it himself). I don't think I could get resources if it's just a  
> busywork exercise.

Opera would be interested in you doing that (or Hixie, but it seems he is  
not) so we could keep building interoperable implementations, if you're  
not happy with SQLite v3.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

[Jonas Sicking-2]

On Mon, Nov 9, 2009 at 3:51 AM, Anne van Kesteren <annevk@...> wrote:

> On Mon, 09 Nov 2009 08:12:22 +0100, Jonas Sicking <jonas@...> wrote:
>>
>> * 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.
>
> From what I understood so far this would also be the case with the Web
> B-Tree Database proposal (maybe even more so given that all SQL
> implementations currently have the same underlying engine). Am I missing
> something?

I don't think this is the case with the SimpleDB proposal. I think
it's possible to for example guarantee that a lookup based on an index
is O(log n) on the number of items in that entity store. Nikunj, is
this correct?

Anne, are there any specific operations you have in mind where you
don't think we can give timing guarantees?

/ Jonas

[Nikunj R. Mehta]

On Nov 9, 2009, at 9:00 AM, Jonas Sicking wrote:

> On Mon, Nov 9, 2009 at 3:51 AM, Anne van Kesteren <annevk@...>  
> wrote:
>> On Mon, 09 Nov 2009 08:12:22 +0100, Jonas Sicking  
>> <jonas@...> wrote:
>>>
>>> * 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.
>>
>> From what I understood so far this would also be the case with the  
>> Web
>> B-Tree Database proposal (maybe even more so given that all SQL
>> implementations currently have the same underlying engine). Am I  
>> missing
>> something?
>
> I don't think this is the case with the SimpleDB proposal. I think
> it's possible to for example guarantee that a lookup based on an index
> is O(log n) on the number of items in that entity store. Nikunj, is
> this correct?

Theoretically, you should get a small single digit as the complexity  
for B-tree look ups. In big-O notation, you are right - it is O(log  
n). The base for this log is typically the number of keys that would  
fit on an internal page, which would be approaching 1000. Therefore,  
practically, even "million key" stores would have a very small  
complexity.

A hash database would have the complexity of O(1), however, this is  
currently not in WebSimpleDB.

The market can figure out what guarantees are possible and desirable.  
Providing guarantees at the API level is the wrong thing to do, IMHO.  
This is because ultimately, a poor implementation can do in a good  
design.


> Anne, are there any specific operations you have in mind where you
> don't think we can give timing guarantees?
>
> / Jonas
>

Nikunj
http://o-micron.blogspot.com

[Nikunj R. Mehta]

On Nov 9, 2009, at 12:58 AM, Maciej Stachowiak wrote:

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

Mobile and iPhone developers are among the quickest to adopt new  
technologies, if I am not mistaken.

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

WebSimpleDB will always remain easy and good to use directly, even  
though it will also support those who want to use libraries on top.  
Whether people would still prefer to use libraries or not, will depend  
on their use case. Specific use cases would help to find a more  
objective solution to your issue.

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

Those applications doing simple boolean index expression evaluation  
could get better performance from WebSimpleDB than with SQLite because  
of the overhead of parsing SQL, generating query plans, and optimizing  
them without knowledge of index selectivity. Knowing the  
sophistication of the average Web developer, such applications may  
dominate the total set of queries run in implementations.

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

Could you help us find the use cases that explain what problems users  
are likely to face with WebSimpleDB? If so, we could adjust the design  
to better support them.

Nikunj
http://o-micron.blogspot.com

[Arthur Barstow]

On Nov 9, 2009, at 8:29 AM, ext Charles McCathieNevile wrote:

> On Mon, 09 Nov 2009 03:44:09 -0800, Maciej Stachowiak <mjs@...>
> wrote:
>
>> 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.
>
> This is not at all the sense that I got. Hixie agreed to specify  
> something
> that he could copy-and-paste, since he doesn't see the value in  
> working
> hard on agreeing to a dialect where two major players aren't  
> interested,
> and others are sufficiently unimpressed by the SQL approach that  
> they plan
> to follow the WebSimpleDB approach.
>
>> The reason is that all parties who currently have or are in the  
>> process
>> of developing implementations did not appear to need 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.
>
> In other words, there is a specified dialogue - but not enough  
> apparent
> energy to try and go further.
>
> My sense is that this much agreement was considered important to  
> justify
> keeping the spec in the WG.

As an FYI on the dialect, Hixie updated the Editor's Draft to include  
the following (note the date on the top of the ED says Oct 29 but  
Hixie actually updated it on 3 November):

[[
http://dev.w3.org/html5/webdatabase/#web-sql

User agents must implement the SQL dialect supported by Sqlite 3.6.19.
]]

>> Note: I would try to find Apple resources to help write a SQL dialect
>> spec if anyone says it will materially help them to have such a spec
>> (and the level of interest doesn't reach the threshold where Hixie  
>> wants
>> to write it himself). I don't think I could get resources if it's  
>> just a
>> busywork exercise.
>
> Opera would be interested in you doing that (or Hixie, but it seems  
> he is
> not) so we could keep building interoperable implementations, if  
> you're
> not happy with SQLite v3.

Given the feedback on implementations [1], I think the next  
publication of Web Database should be a WD rather than a WG Note.

By publishing a WG Note, the group would say it will no longer do any  
work on the Web Database spec. Such a position seems a bit short-
sighted at the moment, given the relative immaturity of WebSimpleDB  
API and the issues raised about it last week [2].

If/when the Web Database spec meets LC criteria (e.g. see [3]), I  
support it being published as a LCWD provided the Editor and WG agree  
to process any comments submitted.

-Regards, Art Barstow

[1] http://www.w3.org/2009/11/02-webapps-minutes.html#item11
[2] http://www.w3.org/2009/11/02-webapps-minutes.html#item14
[3] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/ 
0607.html

[Jonas Sicking-2]

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