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 )
