Hi devs, I'm working on a generic rendering cache system base on configuration. You can see a first version on http://jira.xwiki.org/jira/browse/XWIKI-5110 (The reason why there is already a complete working POC is because it has been tested for a client need and now i'm writing this proposal to integrate it in standard). The idea is to be able to list pages to cache without touching them (that would be more cache macro in xwiki/2.0 syntax or $context.setCacheDuration in xwiki/1.0) and whatever the syntax. = Proposal = 1. The main configuration is a regexp patter based list of document full references (wiki:Space.Page). Here is an example of xwiki.properties configuration: core.renderingcache.documents=xwiki:Blog\..* core.renderingcache.documents=[0-9][0-9][0-9][0-9]_[0-9][0-9]_ The other proposed configuration for now are: is this feature enabled (disabled by default IMO), size of the cache (the size include the number of document and the number of panels for each document which are separated cache entries as well and different languages etc... so it's not the number of cached documents), time to live in the cache (the same for the whole cache, it's a pain to configure something for each document in a central configuration and i'm not sure we really need that). I plan to provide configuration at xwiki.properties and XWiki.XWikiPreference level so the configuration could be different by wiki. 2. Caching is done at XWikiDocument#getRenderedDocument methods level. Currently the POC I did also cache document panels (the result of the panels in the context of the listed document), problem is that at XWikiDocument#getRenderedDocument level it's very difficult to know what is the real current document. All existing way would be hacks since there is no official way to get the panel document from java. Note that you have the same result with $context.setCacheDuration: every rendering done after the call to $context.setCacheDuration is cached and panels are generally rendered after the document content. 3. When a document is modified the cache values related to this document are automatically invalidated. So you don't have to wait to see new content. 4. Each cache value is unique based on the following informations * current document reference * current action * current language * calling URL query string * source (that's how panels are supported, it's same informations except for the source) I insist on the fact that it does not cache the result of the html page but each rendered content. For example all skin and template related content is not cached (menu bar, comments UI, etc...). = Nice to have but not easy currently = a. Extends 2. to also support modifications on included documents. That would be definitely nice and it should be done at some point I think but currently we don't really have any clean generic way to get all documents included for sure (includes inside other macros are not listed by the existing API for example, that would need some refactoring). b. Separate document cache and panels cache. As I already witten that's would need important refactoring to not be a hack. = Side notes = I. This proposal comes with a generic document reference based cache component which take care of the event based cache invalidation system (3.) and support cache keys based on document reference and extensions (4.). We could reuse this component in other document reference based keys caches like image plugin. WDYT ? -- Thomas Mortagne