Introduction
============

TemplateCacheManager is designed to speed up access to content views
while at the same time making sure that stale content is not served
up. TemplateCacheManager is derived from PageCacheManager.


Differences beetween TemplateCacheManager and PageCacheManager
==============================================================

TemplateCacheManager 

  - is independent of the CacheSetup product. 
  - returns also the ETag to the clients, supports therefore cascading caching: 
    Client, Proxy (e.g. Squid) and TemplateCacheManager can cache views of 
    content including header information.
  - generates statistic reports


Installation
============

TemplateCacheManager is designed specifically for caching views of content
objects. Unlike RAMCacheManager, TemplateCacheManager caches both the
html generated by a view as well as the HTTP headers.

TemplateCacheManager builds upon Zope's standard cache manager machinery.  
As with RAMCacheManager, you associate some page templates with the cache 
manager and configure the properties.  TemplateCacheManager requires an
extra step: content to be cached must generate an ETag via a caching
policy.  TemplateCacheManager looks for a CachingPolicyManager with id
caching_policy_manager.  If it finds it, it then gets an ETag for the
current template + content object combination.  This ETag is then used
as the index into the cache.  If you don't have an ETag generated for
your content, your pages will not be cached.

If you create an ETag that changes when the content is changed, then
the content served up by the cache will stay fresh.  There will be a 
cache miss the first time the page is hit after the ETag changes, then
subsequent hits to the newly modified content view will reflect the new
version.  If your content view is personalized, you will want your ETag
to vary depending on the current user.  A good ETag with these properties
is as follows (s. getETag.py script in examples dir):

  ETag = id of currently authenticated user + delimiter + last modified time
    for content + delimiter + current time rounded to the nearest hour

The use of the id in the ETag means that every user's view of a content
object will have a different ETag, so everybody will get different
cached objects.  The use of the modification time means that every time
the content object changes, it will generate different ETags and hence
will result in new copies being pulled from the cache.  The use of
the current time rounded to the nearest hour means that nothing will be
served up by the cache for more than an hour.

Added bonus: TemplateCacheManager handles conditional GETs be
configured by CachingPolicyManager.  If the incoming request has an
If-Modified-Since header with an ETag that matches the content
object's current ETag, TemplateCacheManager will set a status 304
header (Not Modified) and will only return the matching ETag instead
of the content.

