Re: DataCache API - editor's draft available

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.

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.

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();
}


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).

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

Is that correct?

/ Jonas

Received on Friday, 17 July 2009 20:42:42 UTC