[whatwg] Latest proposal for offline web app API
aa at google.com
Fri Sep 21 15:54:47 PDT 2007
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
Other than that, I like the proposal. I am not sure whether we need to
talk about something like Gears's requiredCookie, though.
More information about the whatwg