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

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

Received on Monday, 9 November 2009 08:59:19 UTC