New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explain AppCache in the new API #2

Closed
slightlyoff opened this Issue Feb 7, 2013 · 9 comments

Comments

Projects
None yet
7 participants
@slightlyoff
Copy link
Contributor

slightlyoff commented Feb 7, 2013

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

This comment has been minimized.

Copy link
Member

annevk commented Feb 7, 2013

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

@slightlyoff

This comment has been minimized.

Copy link
Contributor

slightlyoff commented Feb 7, 2013

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

This comment has been minimized.

Copy link
Collaborator

michael-nordman commented Feb 8, 2013

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 notifications@github.comwrote:

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

This comment has been minimized.

Copy link
Collaborator

shinypb commented Feb 8, 2013

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

This comment has been minimized.

Copy link
Contributor

slightlyoff commented Feb 8, 2013

Awesome. Can someone check in the desugaring?

@matthew-andrews

This comment has been minimized.

Copy link
Contributor

matthew-andrews commented Aug 10, 2013

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

This comment has been minimized.

Copy link
Contributor

slightlyoff commented Aug 12, 2013

On Sat, Aug 10, 2013 at 7:00 AM, Matt Andrews notifications@github.comwrote:

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

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jan 24, 2014

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

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Jan 24, 2014

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment