Closed Bug 250856 Opened 20 years ago Closed 19 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: 19 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.