On Wed, Sep 17, 2003 at 10:03:15AM -0400, Tres Seaver wrote: > On Wed, 2003-09-17 at 07:26, Chris Withers wrote: > > Fred Yankowski wrote: > > >>> > > >>> python: content.meta_type == 'Filesystem Image' > > >> > > >>Do you have any content with this metatype? > > > > > > There is nothing in the portal_catalog with that meta_type. But there > > > are lots of objects with that type: most everything in > > > portal_skins/plone_images/, for example. > > > > Oh, I getcha now... hmmm.. since these are served from disk anyway, what would > > be the benefit in caching them? > > > > (Dim memories suggest that OFS.Image.Image does some work to circumvent caching, > > that's probabyl why they'er not being cached...) > > Two reasons: > > - Browser caches know about the HTTP headers, too. > > - Accelerators (Squid, Apache w/ mod_proxy and caching), cache content > to reduce load on the appserver.
Right. I assumed all of that was obvious when I jumped into this thread. The CMF Caching Policy Manager object does not itself cache any objects (unlike the RAM Cache Manager, which does) -- it merely applies cache control headers to set the freshness of some published objects so that downstream caches can do real caching and take some load off of Zope, and perhaps off the network. My original question concerned a detail of how the CMF Caching Policy Manager interprets the 'Predicate' of a caching policy: it seems to interpret any 'content' object in that predicate as a reference to the *parent* object of the object being considered for cache header management. That made no sense to me, and I pointed to the exact code involved, but I still don't know if that code is the result of Undocumented Wisdom or merely a Goof. Meanwhile, back on the ranch, I'm getting good results with this policy predicate: python: content.meta_type == 'Filesystem Directory View' With that, all objects in a Filesystem Directory View get cache control headers. The aforementioned Wisdom|Goof prevents me (AFAICT) from discriminating different meta_types of the individual objects within the various FSDVs, but so far one policy across all such is just fine. -- Fred Yankowski [EMAIL PROTECTED] tel: +1.630.879.1312 OntoSys, Inc PGP keyID: 7B449345 fax: +1.630.879.1370 www.ontosys.com 38W242 Deerpath Rd, Batavia, IL 60510-9461, USA _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )