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

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

--- Comment #22 from michaeln@google.com 2011-12-05 22:34:15 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.

This is where we have to be careful to not break the existing behavior. I'm
fairly certain there are some developers that would not like to see that no
latency characteristic go away.

> 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.
>  - 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.
> 
> Is that right?

Yes to your first points. Less clear on your third point. For some developers,
they'd rather rely on the existing fallback mechanism to handle that case. The
automatic insertion of 'master-entries' is problematic in other ways too, for
example they can't be removed once added, so they'd like to not add them to
start with.

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

I believe the proposal to 'dont-cache-masters' achieves the first two of your
bullets, but not the third.

-- 
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 Monday, 5 December 2011 22:37:05 UTC