[whatwg] Latest proposal for offline web app API

[Aaron Boodman]

On Sep 21, 2007 3:36 AM, Ian Hickson <ian at hixie.ch> wrote:
>  * A set of zero or more strings representing URI prefixes, each
>    mapped to a URI found in the cache (the fallback pages and their
>    opportunistic caching patterns).
>
>  * A set of zero or more URIs that are not in the cache (the
>    online-whitelist set).

I haven't thought enough about this to have a strong opinion, but the
fallback page idea does seem useful.

>  * If you're offline, and any of the caches have fallback pages
>    associated with a pattern that matches the URI of the resource
>    being fetched, then:
>
>       The user agent must pick an application cache from the shortlist
>       of those caches that contain patterns that match the specified
>       URI, and associate the browsing context with it.
>
>       The UA must then use that page, but pretend that it came from
>       the original URI. The page can work out which URI it is
>       impersonating using the document.location API.

Not "offline", but the request failed right? This shouldn't rely on
having the browser literally be disconnected.

> Then, the document must be loaded. If, during load, an application=""
> attribute is found, then, if a cache with that manifest URI already
> exists, then, add the resource URI to that cache, and associate the
> browsing context with that cache. If no cache exists for that manifest
> URI, then create a cache for that manifest URI, and add the resource
> URI to that cache. (XXX How do we handle <?xml-stylesheet?> PIs? XXX)

I didn't understand this bit. I thought that if you had found an
application cache during the previous steps, you load the resource
from that cache and then start the update in the background. I don't
get what's going on here with checking the document for the
application attribute and then adding it to the cache.

>  - If the resource is being fetched via GET, and the cache's manifest
>    and the resources it points to has been fully downloaded, and the
>    cache does not contain a mention of the specified resource (not
>    even in the online whitelist), then fail the load.

This is new. I think this is good, we have wanted something like this
in Gears, but I haven't thought about it enough to have a strong
opinion. The reason we wanted it in Gears was that it is easier to
catch bugs during development with this feature.

>     - if not canceled, tell user update is ready (the page is expected
>       to either call location.reload(), or the API to swap the new
>       cache in, but both could be delayed, e.g. to wait for the user
>       to finish the current task).

>  * Swap in the newest cache without a reload.

This implies that the application can decide when to swap the new
cache in, but I don't think that's true. For example, if a user
decides to open a new window with the application, then the cache will
get swapped in right? Even though none of the apps chose that.

In short, I think the cache should get swapped in as soon as it is
complete automatically. I don't see this as a problem since the
applications have to be ready to handle the new code anyway for the
example above.

Other than that, I like the proposal. I am not sure whether we need to
talk about something like Gears's requiredCookie, though.

- a