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

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

--- Comment #17 from Yehuda Katz <wycats@gmail.com> 2011-12-02 03:42:39 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > 
> > 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.
> 
> No, what they do is they separate the content of the pages from the data in the
> pages, and they fetch the data on page load.
> 
> 
> > 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.
> 
> No, the data will be fetched as soon as the page loads and thus will appear
> just as fast as it would if there was no appcache at all, except the page
> itself will load faster (only the data has to be downloaded, not all the
> supporting app code).
> 
> 
> > 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.
> 
> No, they just use the same pages.
> 
> 
> > 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*.
> 
> Then you lose the entire performance benefit of appcache, which is that you can
> run the app immediately without any network latency.
> 
> 
> 
> As far as I can tell, the use case for the feature being discussed here is that
> authors want to be able to author pages where:
>  - for users who go to a page for the first time, the page loads as now,
> without any appcache stuff.
>  - for users who go to the page again, the UA somehow checks with the server as
> it is loading the page to get a list of which of the resources that are already
> cached for the page can be kept as is and which need to be fetched afresh.

No. The manifest (or alternately, the index page) would be checked for
freshness, and if it was fresh, the app cache's assets would be used. Only a
single blocking request would be required, and only if the UA was online.

>  - for users who go to the page again while the page returns a result other
> than 200, 404, or 410, the UA just uses the old page, the same way appcache
> works today.

It's important that this use-case still wants atomicity of the resources, with
just a single blocking request to determine whether the entire manifest was
stale or fresh, and with the same update semantics as a stale app cache.

> 
> Is that right?

Additionally, if the UA is offline, the UA uses the cached content.

The desire is to have all of the semantics of app cache, especially atomicity,
but a blocking way to determine freshness (in an online UA), instead of always
assuming freshness and determining whether an update is required in the
background.

> 
> We can certainly support this use case, but it's not at all obvious that any of
> the proposals that have been made so far actually achieve this.

-- 
Configure bugmail: https://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 Friday, 2 December 2011 03:42:42 UTC