OK, I've implemented caching support for Silva (using Zope Cache Managers) There is an accelerated http cache manager added on silva install (or refresh), called service_asset_cache_manager. This caching policy can be set per container (and inherited by objects within that container), or set by Silva objects implementing caching support (currently files and images). The policies are set in the properties tab. Since not all Silva objects implement caching support, I've created a new metadata set "silva-caching", with one field "cache_manager". This set is now mapped to Folder, Root, Publication, File and Image. I created a cacheable mixin class that SilvaObject now extends from, which extends from Cacheable and contains two helper methods: validate_cache_manager: This needs to be called before the cache manager is resolved when rendering the content, so that the setting from the metadata can be applied. Changes the cache_manager property ARE NOT applied until this method is called! get_cache_managers: This method returns the values for the cache_manager property. I would have preferred not extending SilvaObject with another mixing class, especially when not all SilvaObjects take advantage of this. Here are some reasons why this was necessary: 1) In order to specify container policies, containers need to have the silva-caching metadata set. This set _needs_ a helper method in order to populate the fields. Adding this method to a mixin and using it to extend the base SilvaObject provides this functionality TO ALL containers without having to alter the definitions for each container 2) Putting this support in SilvaObject provides a path for any Silva object to easily support caching... Had this not been used to extend SilvaObject, each class that is either a container which could contain cacheable objects, or an object supporting caching would need to extend this mixin class. So, how to use: 1) You can specify a cache manager for a container, and this policy is then acquired / inherited by all contained objects 2) For an object supporting caching (i.e. one having the silva-caching metadata set): if no manager is set for the object, it inherits the manager setting from the conainer. It can specify not to use caching, or it can specify it's own cache 3) Since the cache manager is inherited, you can "override" a policy for a cache manager for a container by adding a cache manager with the same id in that container. E.g. The default "file and image cm" is added in the Silva root with id "service_asset_cache_manager". You could set this cm in the Silva root, so it is acquired by all objects implementing caching. In a sub-folder, if you want a different cache manager, or a different settings, you can add a cache manager with the same id, and objects within that container will use this nearer cache manager. Eric: I tested the silva export, and it does not lookup the cache managers during the export, so this is no longer a 'con' Also: there was mention in this issue about allowing only Editor+ to change the cache policy. I believe this could be handled using SilvaMetadata write guards, but it doesn't appear that this has been fully implemented in Silva? If I try to set a write guard in the SMI, I get a 404 error because the python method that is called doesn't have a docstring. If I add a docstring, it still doesn't appear to work. So, please evaluate, and let me know if this can be merged in with the Silva trunk.