Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3C160BA6.EF60EFC8@modperlcookbook.org>
Date: Tue, 11 Dec 2001 08:35:34 -0500
From: Geoffrey Young <geoff@modperlcookbook.org>
MIME-Version: 1.0
To: lindner@inuus.com
CC: Ask Bjoern Hansen <ask@valueclick.com>, Bill Moseley <moseley@hank.org>,
   modperl@apache.org
Subject: Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
References: <20011206103309.C13704@inuus.com>
 <Pine.LNX.4.33.0112110143570.13504-100000@impatience.valueclick.com>
 <20011211023136.C8214@inuus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Paul Lindner wrote:
> 
[snip]
> 
> I suppose that one could put the whole uri->cachefile mapping into a
> custom PerlTransHandler and leave Apache::CacheContent as-is..

yeah, I think that we're starting to talk about two different
approaches now.  the cool thing about the current logic is that no
filename mapping has to take place making it rather fast - basically,
after a simple call to some cached stat() properties and you're done,
Apache's native translation mechanism has done all the work.  the
price you pay for that quick simplicity is stuff written to your
document root.  adding a URI->filename translation step adds overhead,
though it may be preferable to some.  it shouldn't be a requirement,
however.

one of the neat things is about this module is that it makes (pretty
creative) use of method handlers.  the base class comes with
disk_cache(), but memory_cache(), uri_cache(),
i_dont_want_the_file_in_my_docroot_cache(), or whatever can be added
either to the module proper or a subclass.  

so, maybe disk_cache() needs a better and less generic name, like
docroot_cache().

--Geoff