Re: Web Storage & SQL

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?

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.

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?

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.

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.

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

> queries permit user defined functions

Why?

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

/ Jonas

Received on Saturday, 11 April 2009 07:40:47 UTC