Confirmed users, Bureaucrats and Sysops emeriti
1,680
edits
Necko/Cache/Plans: Difference between revisions
→Design Requirements
(→People) |
|||
| Line 24: | Line 24: | ||
== Design Requirements == | == Design Requirements == | ||
* Version API for the cache so we can update easily. | |||
* All APIs should be async. No main-thread locking or i/o at all. | * All APIs should be async. No main-thread locking or i/o at all. | ||
* A crash should not invalidate the entire cache. | * A crash should not invalidate the entire cache. | ||
* Support | * Support gzip compression. Meta-data should say whether a file is gzip'd or not, can choose to write compressed or uncompressed data on a per-file basis at runtime. Pass through files gzip'd from the network. | ||
* Make use of fallocate. | * Make use of fallocate. | ||
* Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API. | * Restrictive XPCOM API, start with just "clear cache." Require a use case to add to the API. | ||
| Line 33: | Line 33: | ||
* Competing ideas: | * Competing ideas: | ||
** Temporal layout so that sub-resources are together. | ** Temporal layout so that sub-resources are together. | ||
** Don't over-optimize on-disk storage, use one file per entry | ** Don't over-optimize on-disk storage, use one file per entry and let OS optimize. | ||
== Performance Goals == | == Performance Goals == | ||