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<[email protected]
> 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
