On Apr 11, 2009, at 12:39 AM, Jonas Sicking wrote:
On Fri, Apr 10, 2009 at 10:55 PM, Nikunj Mehta <[email protected]
> 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.
