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.
--
Brian Akins
Lead Systems
On 5/3/06, Brian Akins [EMAIL PROTECTED] 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
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
Gonzalo Arana wrote:
I am. How about adding it to apr?
How about someone figuring out how to get providers into apr? Doesn't
look horribly hard. Perhaps I should ask on apr-devel?
--
Brian Akins
Lead Systems Engineer
CNN Internet Technologies
On 05/03/2006 09:53 PM, William A. Rowe, Jr. wrote:
And finally (most important) none of this needs to target 2.2. If 2.2
lives
5 months to be replaced by 2.4 - there is really no issue. 2.0 lived
Please keep in mind that some of us are dependent on commercial httpd modules,
whether we
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
Roy T. Fielding wrote:
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
Ruediger Pluem wrote:
Please keep in mind that some of us are dependent on commercial httpd modules,
whether we like it or not.
If the major upgrades happen in cyles shorter than a year I guess it is
hard to get the commercial vendors to provide them. Not everybody is that
innovative and fast
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
Roy T. Fielding wrote:
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
Graham Leggett wrote:
Ruediger Pluem wrote:
Please keep in mind that some of us are dependent on commercial httpd
modules,
whether we like it or not.
If the major upgrades happen in cyles shorter than a year I guess it is
hard to get the commercial vendors to provide them. Not everybody is
On 5/3/06, Roy T. Fielding [EMAIL PROTECTED] wrote:
However, I see no reason to start by changing the existing
module names and assuming that one cache fits all.
For simplicity sake, I agree. Let's call this new thing
mod_cache_generic or mod_frobit. However, let's not touch mod_cache
and
On 05/03/2006 11:27 PM, William A. Rowe, Jr. wrote:
Moreso, we need more third party authors to -participate- in telling us
what
in HTTPD-2.4 will make their module better. And a faster cycle of 6mos-1yr
gives them a chance to do this and realize the benefits in the official
release
On 05/04/2006 12:35 AM, Justin Erenkrantz wrote:
For simplicity sake, I agree. Let's call this new thing
mod_cache_generic or mod_frobit. However, let's not touch mod_cache
and friends for now.
We can rearrange things later if this new architecture actually has
any benefits. I am
On Wednesday 03 May 2006 20:44, 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
Ruediger Pluem wrote:
On 05/03/2006 11:27 PM, William A. Rowe, Jr. wrote:
Moreso, we need more third party authors to -participate- in telling us what
in HTTPD-2.4 will make their module better. And a faster cycle of 6mos-1yr
gives them a chance to do this and realize the benefits in the
16 matches
Mail list logo
