Closed Bug 250856 Opened 20 years ago Closed 20 years ago

Request for standardized cache interface

Categories

(Core :: Networking: Cache, enhancement)

x86
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 135061
Future

People

(Reporter: ciboman, Assigned: darin.moz)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040520 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040520 The idea is, that if the cache would get accessed with a standardized interface (open api and versioning), than other browsers like phönix, firefox or even other browsers or whatever appilcations which fetch html pages could use the cache of all browsers that use that interface as-if it is one cache, and users who use more than one browser which in turn make use of the common cache could possibly benefit with a speed-increase. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Assignee: general → darin
Component: Browser-General → Networking: Cache
QA Contact: general → core.networking.cache
great idea. this will require a shared multi-process cache, which is something that i am working on as part of enabling profile sharing between various mozilla based applications. we already have a cache interface, we just need to make it multi-process safe. the interface is based on XPCOM and is here: http://lxr.mozilla.org/mozilla/source/netwerk/cache/public/
Status: UNCONFIRMED → NEW
Depends on: 135137
Ever confirmed: true
Target Milestone: --- → Future
There could be profile sharing between mozilla based applications on one hand, but independent from this there could be a cache interface on the other hand. The difference would be that the interface needs no union of the involved applications caches, but just provides a handle to use their caches as a ressource. This would not necessarily imply write excess, eliminating the need of a multiprocess model for the cache access. An application A0 would ask for a page P0 in its own cache C0, if not found it would ask in known caches C1-Cn, and update its own cache accordingly if data was delivered. This implies data redundancy, but since most people spend only a few megs for their caches, it is not too expensive, and anyway the caches are their already. As we have learned, the interface already exists and is based on XPCOM. Then the question could arise, if the firefox builders (for example) have plans to make use of existing caches?
It's non-trivial to make use of an existing Mozilla browser cache from another application. Even if you only wish to read that cache, you have to worry about another process making use of it at the same time. Sure, if all processes only read from the cache, that's easy to do. But, as soon as you have one process attempting to modify the cache, all bets are off. You need an interprocess locking mechanism. That is what we will implement when we solve the profile sharing problem. It will enable all Mozilla products to share the same cache.
What about bug 135061? Is this a dup or is this a blocker for that bug?
*** This bug has been marked as a duplicate of 135061 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
No longer depends on: 135137
You need to log in before you can comment on or make changes to this bug.