Re: Web Storage & SQL

On Apr 17, 2009, at 2:39 PM, Jonas Sicking wrote:

> On Tue, Apr 14, 2009 at 9:08 AM, Nikunj Mehta  
> <nikunj.mehta@oracle.com> wrote:
>>
>> On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote:
>>
>>> On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta <nikunj.mehta@oracle.com 
>>> >
>>> wrote:
>>>>
>>>> On Apr 10, 2009, at 3:13 PM, Ian Hickson wrote:
>>>>>
>>>>> On Fri, 10 Apr 2009, Nikunj Mehta wrote:
>>>>>>
>>>>>> Can someone state the various requirements for Web Storage? I  
>>>>>> did not
>>>>>> find them enunciated anywhere.
>>>>>
>>>>> There's only one requirement that I know of:
>>>>> * Allow Web sites to store structured data on the client.
>>>>> There are many use cases, e.g. Google is interested in this to  
>>>>> enable
>>>>> its
>>>>> applications to be taken offline. We recently released offline  
>>>>> GMail
>>>>> using
>>>>> this SQL backend; one could easily imagine other applications like
>>>>> Calendar, Reader, Docs&Spreadsheets, etc, supporting offline  
>>>>> mode. A
>>>>> while
>>>>> back we released a demo of Reader using Gears' SQL database.
>>>>
>>>> Last time I tried this trick I was asked to come back with more  
>>>> precise
>>>> use
>>>> cases [1]. Then I put together more detailed use cases [2], and  
>>>> even
>>>> those
>>>> were not considered to be written precisely enough. So it looks  
>>>> like the
>>>> bar
>>>> for what constitutes a use case or requirement seems to be quite  
>>>> high.
>>>
>>>> [1]
>>>> http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/0079.html
>>>> [2]
>>>> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html
>>>
>>> As far as I am concerned the use cases you enumerate in [2] were  
>>> fine.
>>> However note that even the current WebStorage API makes it  
>>> possible to
>>> address those use cases. Just in a way that is vastly different than
>>> the solution that you propose in [2].
>>>
>>> Do you not agree?
>>
>> WebStorage does not, or for that matter any other speced API, make it
>> possible to intercept PUT/POST/DELETE requests to perform offline  
>> behavior
>> that can be later synchronized to the server.
>
> Indeed. But it does make it technically possible to address the use
> cases that you listed.

Not it doesn't and that is why I have offered the BITSY proposal. http://www.oracle.com/technology/tech/feeds/spec/bitsy.html
>
>
>
>>> I think the main road block to accepting something like that is  
>>> simply
>>> needing more experience in the WG. Since your requirement, or at  
>>> least
>>> your proposed solution, require that the standard design how the
>>> synchronization should work, I personally would like to know more
>>> about other synchronization technologies before accepting your
>>> proposal.
>>
>> I have been working to simplify the requirements to allow
>> application-specified synchronization provided:
>>
>> 1. The browser stores/caches certain URLs à la Gears LocalServer  
>> and the
>> browser responds to GET/HEAD requests for those URLs
>> 2. The browser allows JS interception of requests for non-GET/HEAD  
>> requests
>> to certain URLs
>> 3. The browser enforces cookie requirements for accessing those URLs
>> 4. The browser provides some structured storage JS API for storing
>> synchronization state (not the contents of the data itself)
>> 5. The browser provides JS to contribute content to the browser  
>> store/cache
>> as text (or blob)
>
> So it's entirely the responsibility of JS to synchronize the data?
> Using whatever means already exist, such as XHR etc? Nothing tied to
> AtomPub at all?

This is correct. You can see this from the proposal. We have a JS  
library to synchronize AtomPub data, but this is completely optional.

>
>
>>> So it has nothing to do with lack of use cases, much more to do with
>>> that we're designing a different very API, and so we need different
>>> expertise and background data.
>>
>> At this point, the API that is required for BITSY is far simpler  
>> than it
>> used to be - you can just think of it as a couple of extra methods  
>> to the
>> Gears LocalServer API. That means we have a fair amount of  
>> expertise within
>> this WG - both Google and Oracle have toyed with slightly different  
>> parts of
>> this problem. Oracle has implemented the browser mechanisms above  
>> as a
>> plug-in for both Safari and Firefox.
>>
>> Oracle can provide this specification as a member submission if  
>> that helps
>> the WG.
>
> Of course in order to be able to evaluate a proposal we have to see  
> it :)

Hope to see a constructive discussion now that you can see it.

[snip]

Received on Friday, 24 April 2009 23:07:07 UTC