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/et.al.
modules to a pure get/set/put API (e.g. see the API's of distcached and
memcached at
http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt).
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 et.al.
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.
Regards
Rüdiger
