In response to a cache that provides only bare minimums for functionality, the author seems to be suggesting throwing away all the the cache logic that browser vendors have gone to implement for you, and instead rewriting one's own cache atop LocalStorage and IndexedDB. This seems like a pretty concerning reaction -- or am I simply misreading the author's conclusion?
myscript.js
you name it myscript-[sha1 hash of contents].js
and you set its cache header to expire at some improbably point in the far far future. If you should happen to update the contents of your script file- the sha1 hash will change, and thus its name and its cache entry will also change, in lockstep with its contents. The only fiddly part of this approach is you must also update all references to the new version of the file. If you're clever you can automate this with templates and build systems.What this guarantees is that if your index.html and app cache manifest refer to myscript-[some specific sha1], you're guaranteed that the contents of the script are consistent with what that index.html file expects there.
There was a short video about ServiceWorker at the recent Google I/O that you can check out for an overview[2].
[0]: http://alistapart.com/article/application-cache-is-a-doucheb...
[1]: https://github.com/slightlyoff/ServiceWorker/blob/master/exp...
The last time period that I played around with it was when iOS 3 was out, and it was horribly buggy (if you failed to download all of the things listed in the cache in the first go, then it would break and would refuse to ever try again). By iOS 4 it was less broken, but still weird.
Since it's been out there for a while it would probably be difficult to remove. Because of its brokenness I doubt that it ever got much usage, but there is probably some people out there that rely on it.
What I hope is that after ServiceWorker is better supported, someone can build out the old AppCache behaviour in JavaScript using the ServiceWorker APIs, and then we can use that for compatibility and remove AppCache from the browser itself.
The OP says : only put index.html in the appcache file.
But what about if I want my app to work offline,do I really need to go and shove everything in local storage?
So what's the point of appcache then ? and who went along with that spec at first place?
This specific issue infuriates me.It makes creating offline web app so complicated ,it's like the people writing the spec didnt want developpers to write offline apps.
Just fix the damn spec.
I'm cautiously optimistic about SW, but sad that we didn't just fix the bugs however many years ago so that we at least had something that worked in the meantime.
var s=localStorage["bootstrap"];
if (s) {eval(s);} else {
var t="But you are not carrying the axe!<br>";
t+='<a href="loadup.html">Get the Axe</a>';
document.body.innerHTML=t;
}
http://fingswotidun.com/notanos/Ultimately I found that I needed a server side because of URLs and the same-origin policy. There were just some things that browsers expected to fetch from a URL rather than have the data arrive by other means.
For a time I used a WebDav server to be a dumb server. Eventually the system evolved into https://github.com/Lerc/notanos Which uses it's own custom server https://github.com/Lerc/userserv which uses your unix login and statically serves files that your logged-in user is allowed to see.