Self-Tuning
Generated dynamic content from elements is often not constantly changing, it's therefore quite a waste or resources to generate it completely at each request. It's simple to add a purged map of element+state -> content keys to RIFE since the state is fully known. What would be really cool is to determine a novel approach to setting up the timeout of the cached content.
Most caches allow you to tune the validity time of the content by setting it up explicitely. Some other additional ways might be beneficial:
- trigger content expiration
Make it possible to register some triggers that only are executed when certain conditions hit and expire all related cached material. These could be integrated in an administration interface or in a site structure and point to related cached sections or elements in the site structure.
- self-tuning expiration time
A cached element could initially start with a very low expiration time and monitor if the contents really changed when it's supposed to expire it. If that's not the case, it records the frequency of when content has changed and when not. After a while, it should be able to figure out a sensible expiration average which corresponds to the best update frequency for a specific element.
Asynchronous
When caching results from SQL queries, it's better to cache the results in intermediate result objects (Customer or PurchaseOrder). All access to these objects go through a dedicated manager. The developer registers Obtainers with this manager to describe how the caching system gets the objects. Inserts/updates/deletes either go through the same manager or notify it (event/listener interface) so that it can invalidate cache entries.
Each manager defines a set of named cache objects and registers them with Obtainers. These Obtainers run asynchronously in seperate threads as soon as the manager receives the notification of an invalidated cached entity to replace the invalidated data.
Weighting
Caching should be based on a weighted system.
- Larger ResultSets should be preferred over smaller
- ResultSets that take more time to Obtain should be preferred
- ResultSets that are used more often should be preferred
The caching system should assign a weighted score based on frequency of use / size / time required to obtain new results / time object has been in cache.These weighted scores should be updated at a reasonable frequency and the system should make decisions on which results to purge based on the score. Users could artificially modify a score to hold an object in the cache or force an update.
Memory Limits
The cache should respect a set memory limit and serialize objects to a database table or temporary volitile storage on the disk. Memory limits could be set by number of cache objects or percentage of a specified memory limit.
Fine-grained control
Users should be able to define cache objects that specifiy a "collection of message counts from forums with id = 2" so that that specific query can be cached and updated as messages are added/edited/deleted. That way all message counts are not invalidated by the message add.
The users should register an Obtainer with the information on this query and then should be able to register an EventListener to watch or fire events to that Obtainer or higher-level object. The issue with this method is that the developer needs to have a very specific idea of the caching semantics of the application, which can be difficult in large group situations. Perhaps a searching mechanism (could be slow or drag down system) or a fuzzy matching system (complex, can be wrong) could match queries with the requsite Obtainer. Differences in SQL statements though could make this near impossible.
Policies
- LRU - Least Recently Used
items not used recently are expunged from the cache
- LFU - Least Frequently Used
items which are used most are kept in the cache; unused items are purged
- MRU - Most Recently Used
items used most are expunged first to ensure correct data 
- FIFO and LIFO - First In, First Out and Last In, First Out
items are expunged based on their insertion time in the cache.
- GDSF - Greedy-Dual-Size-Frequency
balanced caching favoring either frequency accessed or size of object accessed
References
Posted by
How could you tell though if the content actually changed? Wouldn't you need to run the element to compare?