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

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

> On Sun, Nov 8, 2009 at 7:24 AM, Arthur Barstow  
> <art.barstow@nokia.com> 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

Received on Monday, 9 November 2009 02:52:48 UTC