Confirmed users, Bureaucrats and Sysops emeriti
1,680
edits
Necko/Cache/Plans: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
= New Cache Plans = | = New Cache Plans = | ||
We have decided to rewrite our HTTP disk cache. | |||
== People == | == People == | ||
The design team will be responsible for coming up with a design for the new disk cache. The design should be thorough and well-documented. Once the design team is satisfied with an initial design document, the implementation team will start implementing. | The design team will be responsible for coming up with a design for the new disk cache. The design should be thorough and well-documented. Once the design team is satisfied with an initial design document, the implementation team will start implementing. | ||
| Line 16: | Line 16: | ||
* Doug Turner | * Doug Turner | ||
* Patrick McManus | * Patrick McManus | ||
Implementation team: | Implementation team: | ||
| Line 22: | Line 21: | ||
* Steve Workman? | * Steve Workman? | ||
== Design | == Primary Design Goals == | ||
This section documents issues that need to be addressed in the new cache's design. | |||
* Version API for the cache so we can update easily. | * Version API for the cache so we can update easily. | ||
| Line 38: | Line 39: | ||
* Separate services fro HTTP and offline cache? Find a way to make these use cases work well without over-complicating code. | * Separate services fro HTTP and offline cache? Find a way to make these use cases work well without over-complicating code. | ||
* Browser should behave properly with disk cache entirely disabled. | * Browser should behave properly with disk cache entirely disabled. | ||
* Allow for effectively racing cache against network, so as to not wait serially. | * Allow for effectively racing cache against network, so as to not wait serially. | ||
== Success Metrics == | == Success Metrics == | ||
This section documents the ways in which we'll determine whether or not the new cache design is a success. | |||
* | |||
* Should not be possible to trigger main-thread i/o. | |||
* Create telemetry for with-cache and without-cache. For top 50% cache should be faster than no cache, for low 50% cache should be faster than no cache. | * Create telemetry for with-cache and without-cache. For top 50% cache should be faster than no cache, for low 50% cache should be faster than no cache. | ||
== API == | == API == | ||
This section documents the APIs for interacting with the new disk cache. | |||
=== XPCOM APIs (exposed to JS) === | |||
=== C++ APIs (exposed to Necko) === | |||
== Locking == | == Locking == | ||
This section describes how locking will work in the new disk cache. Ideally this should document every lock that will be necessary in the new cache. | |||
== On-Disk Layout == | == On-Disk Layout == | ||
This section describes the on-disk layout of the disk cache. It may describe a default on-disk layout and any number of alternatives required for the first revision of the new disk cache. | |||