4 ms·

There's not a fatal error there, afaik. I didn't detail how to deal with un-accessed files because the solution seemed trivial: when your application boots up,

There's not a fatal error there, afaik. I didn't detail how to deal with un-accessed files because the solution seemed trivial: when your application boots up, make sure it prefetches all required assets (i.e. warms the cache) by making ajax requests to each URL. I'm not sure about your interpretation of what does and doesn't constitute appropriate use of a web cache, either. Do you have any examples of the kind of problem you're foreseeing?

jerf 15y ago
"I'm not sure about your interpretation of what does and doesn't constitute appropriate use of a web cache," Not web cache, just plain cache cache. Any kind of cache. Trying to abstract cached content and permanent content with one abstraction is a recipe for disaster, a disaster that leaves you without the proper tools to solve it. It's the sort of disaster that comes up a lot in software engineering where I can not provide a single pithy code example in 20 lines, because they you can always reply with "Well, I'd just write these 25 other lines". The problem is deeper; you've written a semantic confusion into the base primitives of your system and you will pay for it. It's similar to the problem with RPC; you should not and can not simply sweep the difference between local and network communication under the rug. It works small and is incredibly painful in the large. Unfortunately, I can not seem to find a pithy explanation of why this is true. (Perhaps I should write one.) An installed application is not simply a cached version of the website. Even the W3C proposal has gone too far down that road, but the solution is not to keep going even farther.
- deleted 15y ago
  [deleted]
- johnzabroski 15y ago
  > It's similar to the problem with RPC; you should not and can not simply sweep the difference between local and network communication under the rug. It works small and is incredibly painful in the large. Unfortunately, I can not seem to find a pithy explanation of why this is true. (Perhaps I should write one.) I would be willing to help you write it if you'd like. I understand network disruption, partial failure, and weak/episodic connectivity very well, including scenarios where nodes in a network are required to remain radio-silent for long periods of time. Command-and-control military-style systems are much more general than the Web. Related, automatic code distribution is a sort of Holy Grail in programming language design. It is difficult for many reasons. Even data is a huge problem. For example, if the toolbar buttons on Google Docs suddenly die (like they did for our marketing rep a few weeks ago), then the application can become extremely hard to use. Web applications don't handle this well today, and a cache doesn't really address this well, either, because it could be that the new resource invalidates an older cache. In other words, it is a version control and configuration management problem.
bad_user 15y ago
So to "warm the cache" you're basically going to have a list of files that need to be prefetched. Also, in case the network is offline, you need fallbacks for certain unavailable resources. So why not have a standard mechanism for this that doesn't clutter the HTTP protocol? There is a difference between Cache-Control and this offline-cache ... Cache-Control specifies an expiry date (that has to make sense even if you're permanently online, as in you can't put an expiry of 1 month if articles may be updated in far less than that), while the offline cache gets invalidated only when you update the manifest and thus provides an easier to deal with mechanism for the distribution of new versions. I agree with the above comment that you can't really abstract offline away. Offline is offline. People may stay offline from a couple of hours to a whole month and your app has to still function in that period of time - think of Google Reader - personally I like having favorite articles copied locally when I'm going on vacation, but roaming costs are too much for my data plan and I'm definitely turning the net off. So the app has to cache these articles for an indefinite period, but it has to update as soon as I get online (preferably only things that got updated).
- AffableSpatula 15y ago
  Your app should already have fallbacks for 'certain unavailable resources'. I don't think this does clutter the HTTP, in fact the proposal even provides an alternative to the one single addition it does make to HTTP. I'm not clear on the other points you've made, sorry

jerf 15y ago

"I'm not sure about your interpretation of what does and doesn't constitute appropriate use of a web cache," Not web cache, just plain cache cache. Any kind of cache. Trying to abstract cached content and permanent content with one abstraction is a recipe for disaster, a disaster that leaves you without the proper tools to solve it. It's the sort of disaster that comes up a lot in software engineering where I can not provide a single pithy code example in 20 lines, because they you can always reply with "Well, I'd just write these 25 other lines". The problem is deeper; you've written a semantic confusion into the base primitives of your system and you will pay for it. It's similar to the problem with RPC; you should not and can not simply sweep the difference between local and network communication under the rug. It works small and is incredibly painful in the large. Unfortunately, I can not seem to find a pithy explanation of why this is true. (Perhaps I should write one.) An installed application is not simply a cached version of the website. Even the W3C proposal has gone too far down that road, but the solution is not to keep going even farther.

deleted 15y ago
[deleted]
johnzabroski 15y ago
> It's similar to the problem with RPC; you should not and can not simply sweep the difference between local and network communication under the rug. It works small and is incredibly painful in the large. Unfortunately, I can not seem to find a pithy explanation of why this is true. (Perhaps I should write one.) I would be willing to help you write it if you'd like. I understand network disruption, partial failure, and weak/episodic connectivity very well, including scenarios where nodes in a network are required to remain radio-silent for long periods of time. Command-and-control military-style systems are much more general than the Web. Related, automatic code distribution is a sort of Holy Grail in programming language design. It is difficult for many reasons. Even data is a huge problem. For example, if the toolbar buttons on Google Docs suddenly die (like they did for our marketing rep a few weeks ago), then the application can become extremely hard to use. Web applications don't handle this well today, and a cache doesn't really address this well, either, because it could be that the new resource invalidates an older cache. In other words, it is a version control and configuration management problem.

bad_user 15y ago

So to "warm the cache" you're basically going to have a list of files that need to be prefetched. Also, in case the network is offline, you need fallbacks for certain unavailable resources. So why not have a standard mechanism for this that doesn't clutter the HTTP protocol? There is a difference between Cache-Control and this offline-cache ... Cache-Control specifies an expiry date (that has to make sense even if you're permanently online, as in you can't put an expiry of 1 month if articles may be updated in far less than that), while the offline cache gets invalidated only when you update the manifest and thus provides an easier to deal with mechanism for the distribution of new versions. I agree with the above comment that you can't really abstract offline away. Offline is offline. People may stay offline from a couple of hours to a whole month and your app has to still function in that period of time - think of Google Reader - personally I like having favorite articles copied locally when I'm going on vacation, but roaming costs are too much for my data plan and I'm definitely turning the net off. So the app has to cache these articles for an indefinite period, but it has to update as soon as I get online (preferably only things that got updated).

AffableSpatula 15y ago
Your app should already have fallbacks for 'certain unavailable resources'. I don't think this does clutter the HTTP, in fact the proposal even provides an alternative to the one single addition it does make to HTTP. I'm not clear on the other points you've made, sorry