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.
....Roy
