Re: DataCache API - editor's draft available

On Jul 17, 2009, at 1:40 PM, Jonas Sicking wrote:

> On Thu, Jul 16, 2009 at 4:17 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com 
> > wrote:
>> On Jul 16, 2009, at 3:54 PM, Jonas Sicking wrote:
>>> I do understand how Interceptor/DataCache works. And understand that
>>> it's seamless and can (based on a decision made by the browser)
>>> seamlessly intercept both XHR requests and <img src=..> requests.
>>>
>>> What is not entirely clear to me is how you envision that authors  
>>> will use
>>> it.
>>>
>>
>> Authors will use it in all three kinds of use cases I explained  
>> earlier -
>> XHR, form, and hyperlinked data. DataCache is designed to support  
>> all three.
>> The intention is to accommodate any use case arising from the  
>> issuance of a
>> network request when the device is off-line.
>>
>>> I.e. are you expecting authors to want to intercept XHR requests?
>>
>> For data driven applications, I expect this usage scenario.
>>
>>> Or
>>> <img src=...> requests? Or <script src=...> requests?
>>
>> <script src=...> should be adequately supported by HTML5  
>> (ApplicationCache),
>> unless the src value is dynamic in nature. For the static case, I  
>> don't
>> expect to see much usage of DataCache.
>
> Ok that answers my question.
>
> See, what I don't fully understand is what the use cases are. For
> static resources like static images, scripts, plugins etc, it seems to
> me that the HTML5 ApplicationCache should work, as you point out.

Not entirely. Static resources like stylesheets are adequately covered  
by ApplicationCache. Scripts (to the extent they are used for JSON or  
JSONP) are not adequately covered by ApplicationCache.

Moreover, images (when used for more than laying out the page) are  
also inadequately covered by ApplicationCache. For example, how does  
one store a personal Flickr image set using ApplicationCache? I mean,  
if I want to keep a copy of my image sets locally, and keep that set  
synchronized with Flickr, does ApplicationCache (with its requirement  
to version manifests, and require the entire manifest to be statically  
identified and served in a special data format) appear like the right  
thing to use?

Same goes with other resources that require helper applications to use  
for viewing. For example, document attachments also don't appear to be  
well supported by ApplicationCache.

As I see it, the ApplicationCache is primarily for keeping all the  
nuts and bolts that hold together the application pinned in the  
browser's cache. It does not serve a useful purpose for any other kind  
of resources even if the resources themselves are relatively static.  
So the static vs. dynamic resource differentiation needs to be seen in  
a different light. Probably as to whether the resource is user- 
specific or not and whether the resource need is time-varying.

>
> For dynamic images, I think <canvas> is what you'd want to use anyway
> since generating encoded png images and serving it through the http
> Interceptor is a whole lot more complicated.

I am not so interested in dynamic images. If anything, I am looking at  
XML documents, JSONP documents etc. as the dynamic content more.

>
> For loading data using XHR, or submitting data using a form, it seems
> like if the web application is abstracted at a higher level, then http
> interception isn't strictly needed. If you currently have code like:
>
> function readData(callback) {
>  xhr = new XMLHttpRequest();
>  xhr.onreadystatechange = function() {
>    if (xhr.readyState == 4 && xhr.status == 200)
>      callback(xhr.responseText);
>  }
>  xhr.open(...);
>  xhr.send();
> }
>
> Then in order to support offline you could do:
>
> function readData(callback) {
>  xhr = new XMLHttpRequest();
>  xhr.onreadystatechange = function() {
>    if (xhr.readyState == 4 && xhr.status == 200)
>      callback(xhr.responseText);
>  }
>  xhr.onerror = function() {
>    text = readDataFromLocalStore();
>    callback(text);
>  }
>  xhr.open(...);
>  xhr.send();
> }
>

The problem here is three fold:

1. You can't do this with things other than XHR - think about form  
submissions, link navigations, and JSONP script references.
2. The current storage APIs are inadequate for storing resource  
representations (headers and entities - text and binary).
3. Lastly, but most importantly, I lose continuity of the user's view  
over the data, unless I do a lot of extra bookkeeping. Let me explain  
further by continuing with the code you use in the second example above:

Let's assume that the xhr was for a POST or PUT request. Now the state  
of the resource has changed and so no longer is the value of the uri  
used with xhr the same as what it was before the xhr. When  
readDataFromLocalStore (written to handle update requests, and not  
just read requests) responds with the results of this request, I need  
to ensure that subsequent XHRs benefit from that result as opposed to  
a previously stored data, which would be inconsistent with the result.  
This is something interception and dynamic caching allows me to do  
that cannot be done with existing APIs.

>
> So I'm not sure what new use cases we are solving.
>
> What I do agree this new API does is that it allows a *different* way
> to deal with offline. One that could be argued to be simpler (I
> haven't looked into it enough to have an opinion on if it's simpler or
> not).

Where does the burden of proof lie? On the newcomer, I suppose :)

>
> So rather than solving new use cases, it seems like this is providing
> another way to solve them.

It is not merely a different way of solving them. I have argued so  
many times that there are several new use cases here. I have never  
heard any argument to the contrary on the three points above. I would  
be happy to learn that I am wrong on these points, if you are willing  
to oblige.

Nikunj

Received on Monday, 20 July 2009 18:12:09 UTC