Re: Web Storage & SQL

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.

>
>
> However there are some requirements that I think you have which were
> not enumerated in [2] and that are not fulfilled by the current API.
> Specifically the ability to use the same code to implement a strictly
> online application, as one that supports seamless online/offline
> transitions.

That is correct.

>
>
> I.e. the WebStorage APIs require that you monitor all submissions and
> loads to and from the server and redirect the save/load into queries
> into the WebStorage API. It would also be responsible for detecting
> when a user goes online again after having stored data and synchronize
> that to the server as needed.
>
> Your requirements include that a lot of that happens seamlessly, is
> that correct?

Yes.

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

>
>
>>> But we would rather use a standard API than rely on Gears.
>>
>> I think if we are serious about building a good foundation for local
>> persistence, then we should have more precise requirements for Web  
>> Storage.
>> Otherwise, we risk prematurely standardizing some dialect of SQL  
>> supported
>> by SQLite as "Web Storage".
>
> Not sure if it makes a difference, but I would be very surprised if we
> ended up with the same SQL dialect as what SQLite uses. I haven't
> worked with SQLite personally, but from what I understand it uses some
> extensions that doesn't exist in many other database engines. It's
> important to me that we don't lock ourselves into any particular
> database and so we should restrict ourselves to a dialect that is
> widely supported. So for example if you couldn't use an Oracle DB as a
> backend I would be very disappointed.
>
>> Here's a compilation of requirements from what I have read in this  
>> thread
>> and other work I have done in this area:
>
>> queries may involve full-text search, parameterized or query by  
>> example
>> search, or a combination
>
> What do you mean by "query by example"?

 From [1] and [2], QBE is a mechanism to create a query based on  
examples provided by a user searching data. Microsoft Access and  
Siebel CRM both have given QBE access to their users for long and it  
avoids having the user specify detailed SQL queries.

>
>
>> queries permit user defined functions
>
> Why?

UDFs enable specialized processing of application data in a language  
that is easily understood by the application designer.

>
>
>> Application data may only be accessed by authorized users
>
> This *might* be something we can punt to the implementation. I.e. we
> can say it's the UAs responsibility to encrypt the data that the
> application asks the UA to store (no matter if we're talkign storing
> in cookies, localStorage, SQL, AtomDB or whatever). The UA can then
> ask the user to provide a key to access the storage.

Web Storage and Gears have both taken an approach that do not allow  
the server to control access to data once the data has been stored  
locally. This behavior is not acceptable for many applications we deal  
with where the server should be able to detonate the local store if  
certain situations, such as a user logging out, occur.

Received on Tuesday, 14 April 2009 16:10:37 UTC