On Mon, Mar 5, 2012 at 7:47 PM, Brian Smith <[email protected]> wrote: > Patrick McManus wrote: >> Additionally - ability to asynchronously fetch and place items in the >> cache for future use if they weren't currently fresh. > > AppCache does this, more or less. > >> (it wasn't clear to me exactly why manipulating the dom for link >> prefetch didn't do that - though I was assured it didn't.) > > If it doesn't work, then my guess is that link prefetch is only processed > during HTML parsing, so that prefetch links added by JS would be ignored. > > Taras's blog post makes some good points. But, the examples he chose were not > great as far as best practices are concerned. For example, if whitehouse.gov > makes the browser revalidate 95 resources every time it is loaded, that is > not HTTP's fault; that is the developer's fault. A new API isn't going to > help that developer. People who build high-performance websites know how to > make the browser avoid those requests. Many of these techniques have even > been automated into things like mod_pagespeed. > > Even when you have to do revalidation, at least in theory revalidating 95 > entries should be really fast if you have (SPDY or (TLS compression and full > HTTP pipelining)) AND a smart server). The fact that that describes about 0% > of the web is the main problem, AFAICT. And, most of the remaining work on > correcting that has to happen server-side, not client-side. > > If I were a web app developer, in the short term I would try putting as much > in AppCache as possible, for browsers that don't prompt for AppCache. This > should work well unless/until other people start doing so, if the browser > de-prioritizes the eviction of AppCache-cached resources. (Once everybody > does this, then such browsers will have to garbage collect your > AppCache-cached resources just like non-AppCache resources, AFAICT.) Though > long-term, AFAICT, AppCache doesn't really solve any problems unless it is > used as the manifest for explicitly-installed web apps. > > I wouldn't doubt that some IndexedDB implementations are slow. But, I think > IndexedDB can be made fast if it is slow now. There's no reason that an > IndexedDB implementation should be slower than a persistent HTTP cache. I > would think it would be easier to make an IndexedDB implementation faster > than a disk cache than to make a disk cache faster than IndexedDB. What > operations are slow in Gecko's IndexedDB implementation? > > One thing that I think is missing in IndexedDB is a way to indicate which > entries can be safely garbage collected by the browser. Right now, the > browser has to choose to throw away none of the data for a site, or all of > it. This means it can't automatically allow a site to use up to 100MB (say) > of space, and then selectively delete some of it as needed. I think this is > where some kind of cache API like Taras suggested may be helpful. > > FWIW, this weekend I reviewed the use of the nsICache* API by dozens of > extensions on AMO and AFAICT, most if not all of them were prone to race > conditions, at least in theory.
Hmm.. I actually disagree with you here. AppCache is a feature to cache a whole "web app" locally. It isn't designed to be a "normal HTTP cache" enhancement. I.e. if a user is browsing around on your site and you want to either ensure that there's no network request for stylesheets/script/images which appear on most pages, or if you want to prefetch the next page that you think the user is going to browse to, then trying to hack the AppCache to do this for you would be just a hack. I don't think that we should try to bend the AppCache into supporting that usecase. As for using IndexedDB, I think that's too much of a complex solution for pages. It means that you can't simply stick <img src="somepic.jpg"> in your markup. Instead you have to use the DOM and a pile of JS in order to dynamically create a image element which loads data from IndexedDB. It'd work, but it means dramatically changing how people write web pages, IMHO for the worse. / Jonas _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
