httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: very rough caching change patch - centralize vary/http knowledge
Date Wed, 07 May 2008 19:38:34 GMT

On 05/07/2008 06:25 PM, Dirk-Willem van Gulik wrote:
> Apologies for the size - but about as minimal as I can get it :)
> So the problem I see is:
> -    current caching modules should understand things such as
>     Vary and negotiation. And we're bound to get more.
> -    currently only mod_disk_cache does so. There are some 6 or 7
>     other modules which ought to get this capability too.
> -    we can probably improve the current vary and header
>     understanding to get better caching.
> Now we could go all out and reduce the 
> mod_disk/mem/distcache/memcached/
> modules to a pure get/set/put API (e.g. see the API's of distcached and
> memcached at 
> But to me allowing caching modules some knowledge of HTTP is probably 
> good - as
> optimizing the generic case is simply not worthwhile - the very point of 
> caches
> is that they understand something of the biz-processes to go beyond what 
> a the
> operating system and what not can yield.
> So my suggestion is to:
> -    Fundamentally expect modules to understand Vary.
> -    Fundamentally assume that HTTP headers and similar
>     caching info is serializable in a few k's to 10's
>     of k's.
> -    But strip everything out but for the
>         get header data for some Key
>         deserialize something..
>         if (vary_key returned)
>             get header data for vary key
>             deserialize something
>         .. and then work on the body

I am not quite sure if every cache module needs to know this logic. What about a very
thin vary layer that can be moved between the caching client user and the cache provider
itself. Some sort of a meta provider.
I think there is also reasonable use for caches in the code that follow
the pure key/value get/set/put/del as depending on their implementation these caches
can deliver services that the OS maybe cannot out of the box (like distcache for a common
cache across a cluster) or simply ease IPC a lot.

> -    Move all VARY trickery into cache_util

I agree to move more of the VARY trickery to common cache code like cache_util to
avoid code duplications and reinvention of the wheel in various cache modules.

> As opposed to going the pure key/value get/set/put/del route and
> layering something on top of that.
> Thoughts - below is some very rough yet functioningish code.

I haven't had a very close look yet, but the principal ideas sound good.



View raw message