httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: Generic cache architecture
Date Wed, 03 May 2006 20:40:10 GMT
On May 3, 2006, at 12:53 PM, William A. Rowe, Jr. wrote:

> Brian Akins wrote:
>> Is anyone else interested in having a generic cache architecture?   
>> (not http).  I have plenty of cases were I re-invent the wheel for  
>> caching various things (IP's, sessions, whatever, etc.).  It would  
>> be nice to have a provider based architecture for such things.
> Let's talk about httpd.  We have a cache of ssl sessions.  We have  
> a cache
> of httpd response bodies.  We have a cache of ldap credentials.  A  
> really
> thorough mod_usertrack would have a cache of user sessions.
> So really, it doesn't make sense to have these four wheels spinning  
> out of
> sync at different stages of stability and performance.  I'm  
> strongly +1 to
> provide this functionality once, and reuse.

On the contrary, it makes no sense whatsoever to use a generic
storage facility for cached HTTP responses in a front-end cache
because those responses can only be delivered at maximum speed
through a single system call IFF they are not generic.  That is
why our front-end cache is not, and has never needed to be, a
generic cache.

A front-end cache is a completely different beast from a
back-end cache.  It doesn't make any sense to me to try to
make them the same, and it certainly isn't elegant.  SSL
session, ldap credentials, sessions, and all those related
things are trivial memory blocks that *are* suitable for
back-end caching.

I have no objection to creating a module for back-end caching.
I have no objection to creating five different forms of caching
modules, each with its own qualities, that can be selected by
configuration (preferably based on some suggested site profile).
However, I see no reason to start by changing the existing
module names and assuming that one cache fits all.


View raw message