Re: DataCache API - editor's draft available

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  

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< 
> > 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:
>>         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
>> [1]
>> [2]

Received on Thursday, 16 July 2009 22:15:58 UTC