Explain AppCache in the new API

[slightlyoff]

A key design goal of the new API is to allow the existing AppCache system to be explained as a de-sugaring high-level declarative form that is fully explainable in terms of the new controller. Ideally in script.

This repo should include such a de-sugaring.

[annevk]

Not saying it's necessarily a good idea, but we might still be able to remove AppCache from the platform.

[slightlyoff]

I agree, but in order to ensure completeness, layering these in the interim seems worthwhile. I don't think explaining appcache should be construed as a vote for it ;-)

[michael-nordman]

Layering in the interim is probably necessary to allow existing consumer to
migrate where both are used by different (maybe overlapping) parts of a
site. If/when this effort bears fruit we could revisit what to do with
current appcache apis. Probably premature to do so now.

On Thu, Feb 7, 2013 at 8:17 AM, Alex Russell [email protected]:

I agree, but in order to ensure completeness, layering these in the
interim seems worthwhile. I don't think explaining appcache should be
construed as a vote for it ;-)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-13243349.

[shinypb]

Darobin implemented appcache using the proposed API. It's pretty straightforward, only about 60 lines of code for a proof-of-concept.

I think that when a controller is registered, appcache should be ignored by the browser. If developers also want appcache behaviour, they can use an implementation like the above.

[slightlyoff]

Awesome. Can someone check in the desugaring?

[matthew-andrews]

I agree with @shinypb that having both AppCache and NavigationController vying to respond to requests would probably be bad so throwing away any loaded AppCaches after registering a NavigationController seems sensible. Was this decided? I couldn't find anything in any of the explainers...

This would mean some sites might potentially load the offline application twice (once by AppCache and then by NavigationController) only to throw the data from half of those requests away. Since a lot of people are using iframes to load pages that have the AppCache manifest in the html attribute to avoid caching multiple masters they could easily fix this problem by using javascript to add one of those iframes dynamically if javascript detected that the browser didn't support NavigationController. Might it be worth including a section on how falling back to AppCache for a reduced offline experience might be recommended or is that beyond the scope of this spec?

(Ah apologies, it seems like this discussion is duplicated in issue #22)

[slightlyoff]

On Sat, Aug 10, 2013 at 7:00 AM, Matt Andrews [email protected]:

I agree with @shinypb https://github.com/shinypb that having both
AppCache and NavigationController vying to respond to requests would
probably be bad so throwing away any loaded AppCaches after registering a
NavigationController seems sensible. Was this decided? I couldn't find
anything in any of the explainers...

I think the long-term solution is simply to remove AppCache support from
browsers. Contemplating how they interact doesn't seem difficult, though:
as a fully-declarative system, AppCache can be renderer-bound and doesn't
need any thread hopping. Conceptually, that puts it "in front" of
Navigation Controllers. If you register both, you see the AppCache
behavior, falling back to the the NC behavior, then falling back to the
network.

This would mean some sites might potentially load the offline application
twice (once by AppCache and then by NavigationController) only to throw the
data from half of those requests away. Since a lot of people are using
iframes to load pages that have the AppCache manifest in the html attribute
to avoid caching multiple masters they could easily fix this problem by
using javascript to add one of those iframes dynamically if javascript
detected that the browser didn't support NavigationController. Might it be
worth including a section on how falling back to AppCache for a reduced
offline experience might be recommended or is that beyond the scope of this
spec?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-22440258
.

[jakearchibald]

Places we aren't going to reach feature parity with appcache:

Captive portals

Appcache treats x-domain redirects as failure cases for FALLBACK. This is actually problematic as "upgrading" an appcache controlled site from http to https becomes tricky.

In serviceworker we don't expose redirects unless the redirect is generated by the service worker. If you fetch() a same-origin resource a captive portal may give you an OpaqueResponse you weren't expecting. If you fetch() a x-origin resource a captive portal may redirect and you won't know about it.

If you use fetch(sameOriginUrl) to satisfy a navigate fetch, you may wish to do something special if you get a OpaqueResponse back, because responding with this will generate a network error for security reasons.

We're cool with this.

Different appcache for different tabs

Appcache selection is done on navigate. If an update is found, a new tab will use it, even if the other tab is still using the old one. We don't allow two versions of workers of the same scope to control pages.

404 on the worker

In appcache, if the manifest 404'd it effectively unregistered the appcache. We're not doing that. It's stupid. We've got explicit unregister APIs both in the page and in the worker.

[jakearchibald]

ServiceWorker regresses compared to appcache in a few places, with good reason, but vastly exceeds it overall. This ticket no longer makes sense.