- From: Nikunj R. Mehta <nikunj.mehta@oracle.com>
- Date: Thu, 16 Jul 2009 15:13:37 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps WG <public-webapps@w3.org>
On Jul 16, 2009, at 2:43 PM, Jonas Sicking wrote: > Hi Nikunj, > > So one of the things I've never fully understood with your proposal is > what usage patterns people are going to want to use this new API with. Thanks for asking. Please ask me again if this response does not adequately address your needs. > > Is the idea that people that use XMLHttpRequest to load data from the > server will in offline mode want to intercept those XHR requests and > respond with data stored in for example localStorage or some other > type of clientside storage? Without having to change the code that > uses the XHR object? The client would continue to make the same calls during periods of network disruptions - this is why DataCache is transparent. However, instead of the response coming from the server, it would come from the DataCache. Whether to switch to using DataCache, or not, would be the browser's call - this is why DataCache is seamless. The browser can choose to switch depending on a variety of environmental or system conditions. In case where the client access data via XHR, the DataCache can produce either a static or a dynamic response. The static response does not involve any client side storage API - it is generated from the internal storage of DataCache as was populated when a resource was "captured". The dynamic response is produced by some JavaScript code identified as the "interceptor" and it uses any state information accessible to the interceptor, including localStorage (or B-tree storage) and/or DataCache static responses. > > Or is the idea that for things like <img src=...> or <script src=...> > people will in offline mode want to intercept these requests and serve > replies based on data stored in localStorage/elsewhere? In the case where client access data via resource hyperlinks, e.g., <a href=...>, <img src=...> , <object data=...> or <video src=...>, the data could once again be serviced using static DataCache responses. Dynamic responses are also possible but less likely. In the case where client accesses data via form posts, through things such as <form target=...> either programmatically (i.e., form.submit) or not, the data could be servied using dynamic DataCache responses produced by an interceptor using the DataCache static responses and/or localStorage (or B-tree storage). All three cases would be equally well supported by DataCache API. The above processing approaches are the reason why DataCache and HTTP Interceptor are a single API and not two separate ones. > > Or both? > > Or something else? > > / Jonas > > On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com > > wrote: >> I have published the first draft of the DataCache API, which is >> based on >> Oracle's BITSY proposal [1]. Here's a link to the draft: >> >> http://dev.w3.org/2006/webapi/DataCache/ >> This document defines APIs for dynamically and statically >> serving >> off-line representations of HTTP resources. >> >> As the Chairs have concluded this to be within the scope of our >> current >> charter, I would request feedback from you so we can incorporate it >> before >> publication as a working draft. >> >> Nikunj >> http://o-micron.blogspot.com >> >> [1] http://www.oracle.com/technology/tech/feeds/spec/bitsy.html >> [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0098.html >> >> >
Received on Thursday, 16 July 2009 22:15:58 UTC