On Apr 17, 2009, at 2:39 PM, Jonas Sicking wrote:
On Tue, Apr 14, 2009 at 9:08 AM, Nikunj Mehta
<nikunj.me...@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.me...@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]
