[Web-SIG] wsgiMemcached and wsgiAdvogato.

[Ian Bicking]

On Feb 13, 2005, at 1:51 AM, Titus Brown wrote:
> The main problem I ran into with caching was determining when a cache
> entry was stale.  At the moment I implemented a simple function
> 'app.fresher_than(path_info, time_val)' that returns True if the
> cache entry should be discarded & regenerated.  Unfortunately
> this function must then be implemented by the downstream app.  Any
> thoughts/suggestions on this?

memcached is multiprocess/multiserver, right?  If it is, that 
certainly makes things more complicated.

First, I guess there's all the cache-controlling headers.  I always 
found those a little crude, though, as they are all predictive (you 
have to guess how long the cache is valid).  The Vary header is 
interesting, though, since it allows you to indicate other headers that 
the content is derivative of.  Maybe also interesting if you also 
consider WSGI extension headers -- though if you allow that there's 
other issues, like will you hang onto references of objects, and will 
you compare with is or ==, etc.

Maybe a better method would be to emphasize forced expiration of the 
cache.  You could add something to the request that allowed the 
application to expire the value at another URL.  Of course, when you 
add Vary into the mix, you have to allow expiring a URL with specific 
headers.  Or even more complicated -- so there needs to be an interface 
to iterate through some portion of the cache and optionally expire 
things the application encounters.

And of course the expiration may not happen because of a request, it 
might happen outside of WSGI (like some timed task that updates some 
values on the backend), so there needs to be a non-WSGI way to expire 
the cache as well.  Hmm... that all probably makes it much more 
complicated...

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org