[Bug 14702] appcache: always up-to-date applications

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14702

--- Comment #15 from Jonas Sicking <jonas@sicking.cc> 2011-11-12 01:55:00 UTC ---
I'll also jump in and try to articulate the use case.

Consider facebook. Currently facebook doesn't support appcache (at least, for
the sake of argument, let's say it does not).

When the user clicks the facebook bookmark, or types "facebook.com" in the URL
bar, the site is loaded from the network, or if any occasional resources are
cached in the HTTP cache, loaded from HTTP cache.

Same if the user receives a facebook URL through email and clicks said url. The
url is opened in the browser and loaded from network/http cache.

Now say that facebook wants to "enable offline". If they simply add a manifest
to all pages that they want to offline, this means that when the user goes to
facebook the first time in the morning, he/she will see the appcache-cached
version, not the one from the network.

This is not acceptable for this use case. While it's an improvement in
performance, it's a degradation in user experience since the user will see an
outdated version of the website. The downside in this case is a bigger problem
than the gained performance.

For facebook to continue to "work", they have to create a whole new set of URLs
which are only used for the offline version of the website.

However this means that the user has to use a separate bookmark or type a
separate url in the URL bar to go to the offline version. And any links sent to
the user will not work since they are pointing to the online version of
facebook.

None of these things are good and defeats one of the main benefit of webapps,
that you can type a single url to open them.


To fix this, I propose that we change the semantics such that if the UA is
online, the UA is instructed to only use the appcache *after having checked
that the cached version is up-to-date*. In a naive implementation, this
generally means that on the first load the user will not get the version from
the app-cache, but rather load the app from the network.

However UAs can have more smarts than that if they want. For example if the UA
knows that the user uses facebook a lot, it can check that the appcache is
up-to-date even before the user goes to the site. That way, once the user goes
there, the UA has already ensured that the latest version is the cached one and
can load directly from the appcache.

The UA is free to use whatever heuristics to determine which sites it should
aggressively pre-cache. For example if the user has bookmarked the site, has
gone there over 10 times during the past week, is in the list of top 10 sites
the user visits, has created a app-tab for the site, or has through UA specific
UI indicated that they would like the site to be "preloaded", then the UA can
choose to keep the appcache for the site up-to-date.


We could even add a section to the manifest which allows the site to indicate
how often it would like the UA to check for new versions of the app. So if the
site indicates that an update should be checked for every 5 hours, then the UA
can then use the above heuristics to determine if it should aggressively check
that often, or if it should simply check when the user goes to the site if it
hasn't checked in the last 5 hours.

In other words, the semantics of this how-often-to-update value would be that
if the UA hasn't checked for an update more recently than the indicated time,
then the UA should not use the appcache-cached version if the user is online.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 12 November 2011 01:55:09 UTC