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 and
    and multiple ETag caching. Client, Proxy (e.g. Squid) and TemplateCacheManager 
    can therefore cache individual 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. INSTALL.txt in examples directory):

  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-None-Match
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. This
feature is needed if you are using a proxy with ETag support
(e.g. squid), which can cache and handle multiple views of content 
indexed by ETag and Vary header.

Information about ETags
=======================

Basic info:

http://devel.squid-cache.org/etag/etag-header.html

Multiple ETag bug of squid 2.x (patch included):

http://www.squid-cache.org/bugs/show_bug.cgi?id=2112
http://www.squid-cache.org/bugs/attachment.cgi?id=1504
