In bug 1032254, necko will support some variety of cache pinning that will mark cached resources as important. Jason and I were discussing on IRC, and it would be really nice to mark network loads from pinned tabs as pinned or at least more-important, especially if we know from history that those resources aren't going to change. Filing this so we don't forget, but it's at the least blocked on bug 1032254.

Honza/Michal, Looking at the feature list in bug 1032254 comment 2, I'm wondering if the pinned API there is going to work here. For instance, I expect we'd want to flush cache entries for app tabs when a user explicitly clears the cache, and we'd want normal expiration rules to apply when the entry expires (not wait for an app uninstall). But bug 1032254 comment 3 makes it sound like for non-appId loads (normal web content, including app tabs) we'd store the data in the regular HTTP cache, so perhaps the rules in comment 2 don't all apply? What exactly are the rules for storing pinned non-appId data? The other issue here is avoiding filling the HTTP cache with too many pinned entries from app tabs. I don't expect that to be an issue on desktop, but maybe on B2G the pinned entries could take up too much space and prevent regular HTTP resources from getting cached well (or at all). Thoughts?

(In reply to Jason Duell [:jduell] (needinfo? me for lower latency) from comment #1) > Honza/Michal, > > Looking at the feature list in bug 1032254 comment 2, I'm wondering if the > pinned API there is going to work here. For instance, I expect we'd want to > flush cache entries for app tabs when a user explicitly clears the cache, > and we'd want normal expiration rules to apply when the entry expires (not > wait for an app uninstall). But bug 1032254 comment 3 makes it sound like > for non-appId loads (normal web content, including app tabs) we'd store the > data in the regular HTTP cache, so perhaps the rules in comment 2 don't all > apply? Exactly, I changed the list later a bit. > What exactly are the rules for storing pinned non-appId data? So, I introduce a "nsICacheStorage pinningStorage()" that can be used by (not only) http channels to query/store entries that will pin. Someone/something has to tell the channel to use it. It might be a bit confusing why it should not work for appid == 0. That's just an implementation simplification for me, but that can of course be changed. We can store also common web content as pinned. Only problem with that is how to evict it. For appid > 0 it's easy - app goes away - we evict. But how for the common pinned stuff? And also, if there is a limit for the pinned storage, what is the point at all? > > The other issue here is avoiding filling the HTTP cache with too many pinned > entries from app tabs. I don't expect that to be an issue on desktop, but > maybe on B2G the pinned entries could take up too much space and prevent > regular HTTP resources from getting cached well (or at all). Thoughts? Other thing is that the implementation in the current patch (Bug 1032254, v1) we don't automatically evict the pinned entries at all. Since they only have to go away along with the app. Sounds to me like we need another directory + own index and io manager over it to handle this case - to have two quotas or share a quota but evict independently. I would love to de-static both the io manager and index properly (why those are actually static at all?)

Ideally we wouldn't have a quota here, nor strict, never-evict pinning, but more of a "please don't evict this unless space for regular entries is getting tight" policy. The use case is pretty different than the pinned B2G app case. I don't know if a new API is needed here, or if we can just special-case pinningStorage() for the appId=0 case. Note that the B2G browser does not use appId=0 (it uses the "system" appID, which IIRC is 20), so if we ever want to have app tabs in B2G (it's not clear to me that we do), then hacking special behavior by appId is probably not the best approach. In general it strikes me a kludgy.